Description
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:
import Prism from "prismjs/components/prism-core.min.js"; import "prismjs/components/prism-markup.min.js"; import "prismjs/components/prism-clike.min.js"; import "prismjs/components/prism-markup-templating.min.js"; import "prismjs/components/prism-php.min.js"; import "prismjs/components/prism-java.min.js"; export default Prism;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.