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
(chore) dual package #3188
(chore) dual package #3188
Conversation
Look right? @aduh95 |
Thanks for the ping! Let me see if I understand what's the issue this PR is trying to solve. In the Node.js docs, it says:
I don't think we expose a class, so I suppose it's a non-issue.
So that means the user sets Assuming I understand this issue correctly, I think another way of solving it would to let the ESM versions untouched, and add a ".": {
"node": "./lib/index.js",
"require": "./lib/index.js",
"import": "./es/index.js"
},
"./package.json": "./package.json",
"./lib/common": {
"node": "./lib/index.js",
"require": "./lib/common.js",
"import": "./es/common.js"
},
"./lib/core": {
"node": "./lib/core.js",
"require": "./lib/core.js",
"import": "./es/core.js"
}, What do you think? I can try to drop a PR if that helps. |
I think you've always been riding the coattails of a use case we really don't care directly about (yet). 🙂 Honestly ESM browser modules sound like they might more properly belong in our CDN build. I don't think I've quite wrapped my head around "one standard to rule them all" yet... many users aren't on this bandwagon and since we already have a Node.js NPM package and CDN package if there was a ESM browser build I think it may belong in the CDN package. Thoughts? We export an instance of HLJS which means if someone uses two different libraries and one imports us and another requires us that now there will be TWO Highlight.js monoliths, with all different settings, languages, debug modes, etc... this can cause all sorts of weirdness and confusion. To solve this the ESM entry point has to literally require the CJS version - so that this is solved by the require cache - now there is only one HLJS, the one required. This is specifically the solution the docs seem to recommend to avoid there being two instances of our library. Yes, my understanding is it's a Node issue.
Ugh. So that pretty much means no ESM for Node... and we'd only be including the ESM for the browser? |
Is it very different for what this PR is doing? What's the difference between pointing straight to the CJS file or having a a ES modules that does nothing but re-export the CJS module? Correct me if I'm wrong, but only ".": {
"require": "./lib/index.js",
"import": "./es/index.js"
},
"./package.json": "./package.json",
"./lib/common": {
"require": "./lib/common.js",
"import": "./es/common.js"
},
"./lib/core": {
"node": "./lib/core.js",
"require": "./lib/core.js",
"import": "./es/core.js"
},
I think that's fair, I understand my use-case is a bit peculiar and would understand if the project decides not to support it. Another use-case which may be more spread out, there's also bundler users who can benefit from having an ESM-only path (E.G.: when using Rollup, you can drop |
I'm not sure... anything that a user might reasonably require/export that returns our "global" instance would be problematic... but it might be possible to only stub A feel a larger problem here is that our
It's not meant for "raw" use... the code is not compressed, it's not minified, it's not "web-ready". You could use it as is, but I don't think that's something we should encourage. In contrast though, we already ship a web ready package: cdn-assets. I think the discussion we should perhaps be having (right now) is about adding ESM libs to our CDN build and related considerations. Perhaps one day there will be "one package to rule them all" but I don't think we're there yet. Sounds like the kind of thing worth discussing when v12 rolls around. Is there a reason that you couldn't just add |
Out of curiosity how are you intending to get the files from NPM to the browser without a bundler? Are you use using |
But it doesn't include ESM build, does it? It looks like instead it's using It it did include it, sure I'd use it, but.. why not use the NPM package? As I said in my previous comment, bundler users also benefit from having ESM available.
import highlight from './node_modules/highlight.js/lib/core.js'; |
Not currently, I did say "if"...
Technically someone wanting "pure esm" could use the CDN assets version I suppose... UGH. What a pain. I really just don't have any more bandwidth for this.
The still makes me think you're bundling... how does that actually get on the web server? Are you just copying ALL of |
Bottom line: We already have a ton of infrastructure, history, documentation around making our web builds available via CDN (and secondarily) via NPM... if we do have an ESM library that is intended for use on the web then it should be built with This is irregardless of what happens or doesn't happen with the |
Let me say that I really appreciate the time you put into this and the consideration you gave to my request, no matter if it ends up in the v11.x release or not! I'm really sorry if I'm giving you more work, and I understand if you are not interested to invest more time into it. |
The problem is now that I've given it thought: ESM builds intended for directly use as-is on the web (your stated use case) should be in our CDN build - that's where people who aren't bundling look to find our web assets... that makes this patch (which I still don't fully understand) much less interesting. Your use case should instead by solved by just adding pure ESM modules to our web CDN distribution. Hence #3199. And if that should require breaking no APIs then that could be done at any time in the 11 cycle. |
I think I agree, if there's a web focus dist which can work with ESM, there's no need to discuss compatibility with the npm package. I just need to remember to use the cdn-assets NPM package when I want to work offline.
tbf I'd do that only when starting new projects (I.E. before I try to add a bundler/minifier build-chain), or for toy-projects for which I don't bother optimising in any way (typically I would transform to unpkg URLs before pushing to prod though, if I ever go as far). |
Per https://nodejs.org/api/packages.html#packages_writing_dual_packages_while_avoiding_or_minimizing_hazards