Any thoughts on extracting the Parser, Virtual Tree Abstraction, and Documents into their own thing.

[DamianReeves]

I'm working on something that needs to process source files in general and I like the Laika architecture. There are callouts in the documentation about portions of Laika being used in other contexts, and I think that is a good possibility similar to the UnifiedJS platform

[jenshalm]

There are currently no plans to release Laika in a set of smaller artefacts. There are three reasons for this:

1. The library is already split into several jars, it's just the case that some of them, like laika-core are a bit monolithic and contain more than one module. The current separation between artefacts is based on the kind of 3rd-party dependencies that a module depends on. For example, laika-io adds a dependency on cats-effect, laika-pdf on Apache FOP, laika-preview on http4s and so on. Which means that if you want to use just the AST and virtual tree abstraction, you can simply depend on laika-core. This will then contain a number of packages that you don't need, but the separation by 3rd-party dependency means that your classpath will not be polluted by any other dependency that you don't need.

2. While it is theoretically possible to publish Laika in even smaller modules (a set of 12-15 micro-libs would be possible as the internal modules are well separated), there isn't any significant demand from the community for this - you are the first user to ask.

3. Splitting Laika into even more modules increases the maintenance burden, and as long as Laika is, for the most part, a single-maintainer project, this is not going to happen.