How do you use lowlight with hljs v11 support with cjs/node?

[NullVoxPopuli]

I see that the package is built with target: ES2020, which is great! except that node/CJS is still a mess with cjs<->module compatibility

if I want to use Node/cjs, how do I use lowlight / rehype-highlight? Is there a way to tell rehype, and/or maybe remark to not use lowlight, and use highlight directly?

[wooorm]

Is there a way to tell rehype, and/or maybe remark to not use lowlight, and use highlight directly?

No, there is not.

ll with hl@11 can be used currently by depending on main, and soon when hl@11 is released.
It’s also possible to use it through Node 12+, in ESM.
But it’s not possible to use CJS with ll@main.

You’ll have a couple problem with rehype-highlight and ll@main for now, but that’ll be solved when hl@11 is released. You could bundle them and use that bundle. But I’d suggest switching to ESM

[NullVoxPopuli]

But it’s not possible to use CJS with ll@main.

gotchya -- so I really just need hljs v11 to be released so all the the remark/rehype packages ship cjs in npm.

Thoughts on bundling the dist files on the main branch as hljs-glimmer does? This way it doesn't matter what's unreleased, folks can still point at git and stuff "just works"

But I’d suggest switching to ESM

if I weren't integrating with an existing node ecosystem, this'd be an option! But I'd have to convert thousands of files and maybe hundreds of packages to ESM before I could finally use lowlight via ESM

[wooorm]

gotchya -- so I really just need hljs v11 to be released so all the the remark/rehype packages ship cjs in npm.

remark/rehype will turn to ESM soon too, and stop shipping ESM

Thoughts on bundling the dist files on the main branch as hljs-glimmer does? This way it doesn't matter what's unreleased, folks can still point at git and stuff "just works"

Against it. Dual publishing has a lot of problems too.

if I weren't integrating with an existing node ecosystem, this'd be an option! But I'd have to convert thousands of files and maybe hundreds of packages to ESM before I could finally use lowlight via ESM

I’ve ported 200 projects over already. And will port 200+ more over these months. It’s a lot of work. But it’s the future. Also: ESM can use CJS just fine. You can port one project over that depends on CJS without a problem

[NullVoxPopuli]

ESM can use CJS just fine

Yeah, my issue is more that I need the other way around to work :(

Dual publishing has a lot of problems too.

what problems?

remark/rehype will turn to ESM soon too, and stop shipping ESM

I mean, if breaking changes are what get all of the node ecosystem to move to ESM, that's great. This feels like an awkward transitional period where we don't have forwards compatibility though (only backwards compatibility)

[wooorm]

Say you depend on project a and b. A and b depend on project C. But a is cjs and b is esm. Now you ship ywo different copies of C. They might just duplicate code size. Or they might interfere. That's quite a problem.

In practice, I've also noted this. I shipped micromark half a year back as dual. And it broke a ton of folks on webpack 4, which can't deal with it properly.

Tooling needs to catch up to esm. And it's not going to be easy. But the only path forward I can see is making that cut and switching

[NullVoxPopuli]

They might just duplicate code size

With different package.json entries for main / module / browser how would code size increase? only the used code is required/imported, not the whole thing.
How would the interfere? A module-loading / bundling system knows how to interpret main/module/browser.

Tooling needs to catch up to esm. And it's not going to be easy. But the only path forward I can see is making that cut and switching

agree with ya there

[wooorm]

https://nodejs.org/api/packages.html#packages_dual_package_hazard

[joshgoebel]

Please don't keep reminding me of dual packaging problems. ;-)

[wooorm]

Closing this as there’s I’m not going to add CJS support here, and I’ll release the code on main when hljs is ready!