Keep unminified code in package build

[victrme]

Hello @FIameCaster, I absolutely love your work! We are going to add prism-code-editor for our extension because it is perfect for us.

Is it possible to keep the full code in the package instead of publishing it minified ? The problem is that we ship unminified code and debugging is pretty difficult when minified.

I can fork prism-code-editor and keep it synced if you decide not to go with this, so it's fine!

Thanks 😃

[FIameCaster]

Hi @victrme, great to hear you like my library!

Currently, the package contains minified code with source maps for debugging. These source maps work well for me. Could you specify why source maps aren't sufficient for you when debugging?

Since this library is not meant to be used through a CDN, publishing the package with unminified code is fine. With unminified code in the package, it won't be a big deal if the source maps don't work, but source maps should still be included IMO since the unminified code is still less readable than the source code.

Another advantage of not minifying the package code is that inspecting the code on the demo website will improve since the source maps for the package don't work there.

I think I will remove minification of JavaScript (not CSS) for version 3.2.0. Hopefully I can finish it later today.

[victrme]

I just added the sourcemaps and it is working fine, I kind of forgot about it... Since our script is bundled but not minified, we never had to worry about sourcemaps 😅

But yes, what we see usually with other libraries is that the minified version is available for download somewhere, and the node module is as close to the source code as possible to avoid bundler conflicts or compatibility issues. Vite will minify based on your "es2020" target, but someone using an older target might run into transpiling issues! That's an edge case, but still something to consider I think.

Another advantage of not minifying the package code is that inspecting the code on the demo website will improve since the source maps for the package don't work there.

That's is a great point!

I also think that there is a need for sourcemaps because Vite library mode generates a very obscure output, with extra exports everywhere and hashing in filenames. It might be possible to improve the output in the build config, but I don't know vite/rollup enough.

I think I will remove minification of JavaScript (not CSS) for version 3.2.0

Yes minified CSS is no problem, thank you !

[FIameCaster]

What we see usually with other libraries is that the minified version is available for download somewhere

For packages with a single entry point, this makes sence, but for a package that's as modular as this package, it doesn't.

Vite will minify based on your "es2020" target, but someone using an older target might run into transpiling issues

My thought process is to keep the package's code fairly modern so the bundle size is smaller for people who don't need great browser support. If they do need better browser support, they can transpile away features like optional chaining and nullish coalescing in their own build step. Either way, this package relies on beforeinput input events that can't be transpiled or polyfilled, so a build target lower than "es2018" makes little sense.

Either way, I hope you'll enjoy adding an editor to your browser extension!

[victrme]

Right, that makes sense. Thank you for your insight !