joshgoebel
commented
3 years ago Another idea is to have the npm package include a Prism bundle that includes all languages ... easy-to-use solution for people who just want to try out Prism or don't care too much about bundle size.
It probably also works great for many on the server-side if they aren't paranoid about application start-up time since Node.js is quite fast at parsing code. Our Highlight.js NPM package distributes an index.js that loads EVERY language and our README includes instructions showing using it in that fashion or (for the more selective people) loading individual grammars one at a time.
We don't have the same inter-dependency issues as you all because we decided to handle hard dependencies at build-time (and our NPM package is a build asset, not raw source code)... although I suppose we still have soft dependencies (HTML can include CSS, etc. If CSS isn't loaded you don't get CSS highlighted in your HTML.)... and we do rely on users to get those right (and they do most of the time).
If they need help they can always look at our own index.js to get the 'correct' canonical load order (with soft dependencies resolved) - or build a custom monolith JS file with our build scripts.
Motivation A lot of people seem to use Prism via ES6 import declarations and get it wrong.
Each language definition has a list of languages it requires and optional dependencies. This information is an implementation detail and hidden from our users but also required to make static imports work.
Our current solution for this problem is the Babel plugin. However, users may not want or have the option to use this plugin, so I think that we should also offer an alternative solution.
Description I really don't know how to solve this in a robust manner since we essentially have to control the user's source code.
Maybe a few ideas:
A Prims CLI interface that generates an import file like this:
npx prismjs import-file --languages=html,php,java --js-out=./src/prism-importer.js(Users will then import the generated file instead of our package.)The generated file will look like this:
The problem with this approach is that the generated file is version-specific and may silently fail. The easiest solution for this is to include a version check in the generated file but I'm not sure how to do this efficiently.
Another idea is to have the npm package include a Prism bundle that includes all languages to eliminate the need for multiple static imports. This completely throws away Prism's modularity but it's an easy-to-use solution for people who just want to try out Prism or don't care too much about bundle size. Also, this doesn't help with plugins since they have the same dependency problem.