-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite prism in esm #2715
Comments
Is the |
Well, you don't have to write the wrapper by yourself. Rollup, esbuild and webpack both handle (most of the) cjs libraries (including react) well. The advantage of using esm is all about tree-shaking. You can treat preact as an example. |
How would tree shaking help a tiny library like Prism that is already super-small and (I presume) most of the functions present are actually truly required for the highlighting process - hence they can't be shaken...
Well, yeah, I know things can be automated... but Prism has 100s of files... so I was asking if the ESM would be a top-level wrapper that just requires something else, or if every one of those 100s of files would need both a CJS and ESM version... |
It won't. Right now, Prism Core only contains one small function that isn't necessary for the highlighting process. But even that function can't be "shaken off" because Prism Core doesn't export individual functions, it exports a Prism instance so all functions are instance methods. As it is right now, Prism won't benefit from tree shaking at all. That being said, we do plan to go to ESM with v2.0. This will require significant changes to our build pipeline, so generating a CJS and ESM version of Prism shouldn't be an issue then. |
What does that look like then? Is there then both a ESM and CJS version of every single grammar file? IE, an entire sep CJS vs ESM folder depending on how one wants to use it? We're debating ESM for v11 for Highlight.js right now. |
That's what I had in mind. Since these builds are all generated for us, it's an easy and convenient way to support both. That being said, we are still in the early stages with the ESM idea, so nothing is final yet.
I thought HighlightJS was already using it? |
For the raw source, yes, since v10. But our "cooked" source (web distributable, NPM library, etc) is all CJS. Everything is run thru rollup to build the distributable. |
It looks like ESM output has been added to Highlight.js now: highlightjs/highlight.js#3007 |
I'm not sure we'll stick with conditional exports though, we're going to see how the v11 alpha/betas work... might end up just being two folders and someone has to specify the path they want. And of course for many simple use cases we still recommend our pre-built CommonJS monolith CDN build, which behaves pretty much the same as it always has. |
Is ESM still in discussion for Prism? |
It's planned for v2, so yes. |
Implemented in v2. |
@RunDevelopment has v2 been published anywhere? presently banging my head against v1.x trying to load relative files via require. |
I created a Vite plugin that can effectively solve the issue of importing PrismJS. https://github.com/hex-ci/vite-plugin-prismjs-plus |
Motivation
Many modules are supporting esm now, it is better for bundlers to do tree-shaking and do care node.js and browser environment with separated bundle.js.
Description
Bundlers like rollup or webpack want to see esm modules and they do tree-shaking for smaller size. Currently you're using cjs and supporting both node.js and browser by hand (instead of umd). This is bad bacause it exports some global variables like
_self
in browser and you won't be able to use it in the native esm way becauseimport
s order is not guaranteed. See vite#1438 since vite depends on native esm in development mode. This solution is also wrong.As a result, your package.json should look like this:
The text was updated successfully, but these errors were encountered: