search

jgm / skylighting

A Haskell syntax highlighting library with tokenizers derived from KDE syntax highlighting descriptions
189 stars 61 forks source link

Dependency footprint #152

Closed benjamin-hodgson closed 1 year ago

benjamin-hodgson commented 2 years ago

skylighting-core has a few dependencies which are only used for certain output formats: ansi-terminal, blaze-html, etc. Would you be open to making those dependencies optional? Either via compilation flags or by extracting the formatting modules into separate packages.

jgm commented 2 years ago

No, not by compilation flags, because the API is not supposed to depend on cabal flags.

So it would have to be by splitting the rendering functions (Skylighting.Format) into a separate package. I'm open to that suggestion, but (a) that would take a lot of my time, and it's not a high priority for me; and (b) this would be a breaking API change that might inconvenience other users.

benjamin-hodgson commented 2 years ago

Thanks for getting back so quickly!

One could do it in a non-breaking fashion, by leaving the formatting code in skylighting-core and extracting an "even more core" package containing everything except the formatting code. skylighting -> skylighting-core -> skylighting-corer. (Not saying that's a good design, just that it's doable!)

If the level of effort is the main issue here, I'm certainly prepared to help with that!

jgm commented 2 years ago

Can you say why the dependency issue footprint is so important to you?

benjamin-hodgson commented 2 years ago

Just the usual reasons: slows down initial build, inflates binary size, more things to audit, potential for upstream security issues, potential for dependency solving problems. An app which doesn't write HTML shouldn't need blaze as a dependency.