This is a minor release that addresses some technical issues and features which, while important to do, probably won't apply to most users.
Planning to upgrade? Review instructions in the README.
Frontend
- Added support for CSS subgrids
Backend
- Updated class loading logic to better separate dependencies used by the user's code from dependencies used by the backend. This makes the Kobweb backend code a lot more robust and future proof.
- A concrete example can help here. The Kobweb backend uses kotlinx serialization, but as a user, you might also use it in your own site, and perhaps you're using a slightly different version of it. Before, the Kobweb server would just find and use its own copy of the serialization library which it would hand to the user code, which almost always works fine but could potentially result in confusing crashes if any API call you were using was different between the two. Now, the user code will always get to use its own copy of the library.
Markdown
- Fixed an issue with absolute paths in markdown breaking on Windows.
- If your markdown file had a line like
link to [some markdown](https://some.example.site.com/path/to/some/markdown.md), that would crash when running on Windows. ("Cross platform" path APIs are fun....)
- If your markdown file had a line like
Gradle
-
The library plugin now generates a
module.jsonfile for all of its artifacts. This allows the application plugin to detect that an artifact was build by the Kobweb library plugin as well as which version it was built by, in case that matters in the future.- Before, the application plugin would copy over any resources found under a
resources/publicfolder in any library into your final site's public resources. That logic has been updated to only copy files from libraries we are sure were built with Kobweb.
- Before, the application plugin would copy over any resources found under a
-
If you are a library author who wants to write code that requires the user add script includes into their site's
<head>block, you can now specify them yourself in the library'sbuild.gradle.ktsfile and they will be included in the user's site automatically.- The user will be notified of this and given a chance to opt-out of auto-including head elements on a per dependency basis.
- See the notes section below for an example.
Notes
Specifying head elements from the library plugin
A concrete example will help here. In v0.0.6 of the Kotlin Bootstrap library, the user is asked to add some code into their build script in order for the library to work.
The author of that library can now do this in their own build script:
kobweb {
library { // <-------------- Note "library" here, instead of "app"
index {
head.add {
script {
src = "https://cdn.jsdelivr.net/npm/bootstrap@5.3.1/dist/js/bootstrap.bundle.min.js"
}
link {
rel = "stylesheet"
href = "https://cdn.jsdelivr.net/npm/bootstrap@5.3.1/dist/css/bootstrap.min.css"
}
link {
rel = "stylesheet"
href = "https://cdn.jsdelivr.net/npm/bootstrap-icons@1.11.0/font/bootstrap-icons.css"
}
}
}
}
}and with that, they can publish their library, and anyone using Kobweb v0.15.1 or newer will have those head tags automatically added for them.
If a user wanted to opt out of adding these dependencies automatically, they would add the following into their own application build script:
kobweb {
app {
index {
// The name "bootstrap" was reported by the Kobweb application plugin when
// it detected that head elements were being added in the Kotlin Bootstrap artifact.
excludeTagsForDependency("bootstrap")
}
}
}Full Changelog: v0.15.0...v0.15.1