Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Laika API link configuration #462

Closed

Conversation

reardonj
Copy link

This PR sets up the Laika configuration for API links, based on a map of package prefixes to scaladoc URLs provided by the plugin user. If none are provided, it will default to tlSiteApiUrl if available.

This allows links to the API docs to be easily added to Typelevel microsites, eg.: @:api(cats.data.Chain)

This implementation is based on the review comments for #225 and will supercede that PR.

@@ -85,6 +89,7 @@ object TypelevelSitePlugin extends AutoPlugin {
override def buildSettings = Seq(
tlSitePublishBranch := Some("main"),
tlSitePublishTags := tlSitePublishBranch.value.isEmpty,
tlSiteApiLinks := tlSiteApiUrl.value.map("*" -> _).toMap,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately the tlSiteApiUrl is not the "base" URL for the API. See (1) in #225 (comment).

So maybe we need to add a tlSiteApiBaseUrl or something ...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also wonder if it would be helpful to populate this with some useful defaults. Like for Cats and Cats Effect and stuff, since I assume downstream documentation will want to reference it fairly frequently.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's too bad, tlSiteApiUrl worked fine for Cats. Is there a reasonable situation where stripping off everything after the last / wouldn't work? Or only defaulting to tlSiteApiUrl if it ends in / ?

If tlSiteApiBaseUrl would only be used for tlSiteApiLinks, we may as well just have users populate tlSiteApiLinks themselves instead of adding yet another setting.

Is there a way to get those common library versions inside the plugin? I wouldn't want to embed specific versions in the defaults.

Copy link
Member

@armanbilge armanbilge Jan 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reasonable situation where stripping off everything after the last / wouldn't work?

Yeah, so for example http4s-dom sets its tlSiteApiUrl to this, so it "zooms" to the right package.

https://www.javadoc.io/doc/org.http4s/http4s-dom_sjs1_2.13/0.2.6/org/http4s/dom/index.html

So I don't think it would work there.


tlSiteApiBaseUrl can be used to make tlSiteApiUrl and in many cases it will be auto-populated by the unidocs plugin. tlSiteApiUrl wasn't the right primitive.


Is there a way to get those common library versions inside the plugin? I wouldn't want to embed specific versions in the defaults.

Ugh, good point, I forgot about this trickyness. Blah. We could try scouring the classpath for this information but it's a bit hacky. I have to think about this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way to get those common library versions inside the plugin?

Actually, we should try and use the same mechanism that sbt uses for API mappings. These are read out of the dependencies. Essentially Laika is replicating this same feature, we just need to glue them together. This might even be upstreamable into sbt-Laika.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So have we circled back to providing tlSiteApiBaseUrl then?

I think you also have to provide your package as well? Funny enough we might have an existing setting for that.

But I want to think about this more.

Copy link
Author

@reardonj reardonj Jan 31, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

…on the other hand, given the dream is to obsolete most of that config, and it's a one time bit of work on the project being documented, maybe it's best not to add more machinery. here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you also have to provide your package as well? Funny enough we might have an existing setting for that.

You can provide "*" as an explicit fallback (which is what the case class defaults to) and it handles that specially as a fallback if there is no match. So you don't need to provide your own prefix.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, but what happens if my project is org.http4s.dom and sbt-typelevel had pre-loaded org.http4s API docs for me. It just doesn't work in general.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uhh; right

@armanbilge
Copy link
Member

For testing, can we try dog-fooding this in the sbt-typelevel documentation?

Comment on lines +116 to +119
.withConfigValue(LinkConfig(apiLinks = tlSiteApiLinks.value.toList.map {
case (packagePrefix, baseUri) =>
ApiLinks(packagePrefix = packagePrefix, baseUri = baseUri.toString)
})),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the order here matter? e.g. what happens if the cats prefix comes before the cats.effect prefix?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Order doesn't matter, Laika uses longest prefix match.

@reardonj reardonj closed this Feb 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants