Hi i would love to refactor this to ESM

[frank-dspeed]

Hello i would love to refactor this to ES2020 and build a CJS version for older NodeJS versions pre v13 if your ok with that simply send me here a msg and i issue a PR Else i will fork Complet as i need this to be ESM and in the browser

#308

[43081j]

@inikulin this has to happen IMO, it would be great if you could let us know your preference on how to move forward with it so it can be done and out of the way

even better would be converting to typescript.

this'd also lead to removing those not-so-great export assignments from the old school commonjs too, which would clean up the typescript types a lot (whether they live here or not).

@frank-dspeed do you actively have a branch anywhere which you've started/completed this on?

happy to help if needed

[frank-dspeed]

@43081j i have started it but did not finish it but i am able to do it again in one step as i am specialised on upgrading CJS => ESM i would prefer to upgradae it to ESM only but in a way with JSDOC Anotations so that the types get correctly shown inside every IDE that uses the typescript language server..

I Will start that task now you can simply post a comment here if you want to go directly to typescript as i am not so open to do that.

[inikulin]

Hi folks, frankly speaking haven't followed the JS world for a while. I assume #329 is related? Would be happy to accept PRs

[43081j]

Yes exactly.

Worth noting too that the ideal here is to write actual esm or get the build process to output such code. Such that it works in both browsers and node.

It's tempting to fake it by wrapping some cjs in esm, but please don't as it won't work in browsers.

We could either use a bundler to generate an esm bundle or rewrite the modules as proper es modules (export/import instead of require).

[wooorm]

@inikulin Reading through https://twitter.com/sindresorhus/status/1349294527350149121 might be of interest.

FWIW, supporting both ESM and CJS is also complex: I recently published a low-level package, which was used through a couple of CJS packages, but when users bundled higher package with webpack 4, it all broke.

Supporting only ESM is also currently complex, e.g., webpack loaders cannot import yet.

The push that Sindre, me, and others will be doing soon to support only ESM will be a challenge for the ecosystem, but then the dust will settle. So it’s definitely something to think about soon.

[43081j]

while im all for the push to esm-only, it is true it'd be a huge change and pretty abrupt.

i'd recommend rewriting it as ESM but using esbuild or something to output a CJS bundle equivalent (so the packaged individual files are pure ESM, but there is a bundle alongside which is CJS).

that isn't so complex and is what I and many others in the web side of things currently do.

even better would be typescript so we can stop maintaining the types at DT. but thats a bigger job especially from the current state (lots of stuff typescript wouldn't be happy about).

[frank-dspeed]

@43081j @wooorm i also regonized all that and my final Way to go will be a ESM only version this can then get transpiled via babel to cjs or with anything else.

Then the ESM version gets released as new Major version and can get used with current NodeJS via import() inside CJS

the README will show instructions to create a CJS version if needed. And it will point out that this new Major Version is Only ESM and to use it you will need NodeJS Version > 9.7.x or the npm esm package.

What do you think about it?

NodeJS ESM Support

• NodeJS 13.2+ .use import or import()
• NodeJS 9.7+ use --experimental-modules then use import or import()
• NodeJS 6+ use "npm install esm" then use import or import()
• With TypeScript or with node-ts you can use it inside .ts files.
• Most other Environments like Current Browsers and Deno or GraalJS will also work out of the box

[43081j]

that makes sense to me, and i would argue it is not complex at all to support CJS and ESM:

esbuild lib/index.js --platform=node --bundle --outfile=parse5.bundle.js

as long as the sources are ESM, all is fine. parse5 has no dependencies IIRC, so its pretty straight forward.

[frank-dspeed]

@43081j its not so easy for the engine to figure out the right version and it would add bloat thats not needed as explained before its a edge case to transpile it to CJS

[43081j]

package exports:

  "exports": {
    "import": "./lib/index.js",
    "require": "./parse.cjs"
  }

the bloat of having to duplicate the code into a bundle is inevitable.

then one day when people finally progress to the standard (ESM, which will be a slow job since the node team don't see it as a "progression"), parse.cjs can be dropped.

[frank-dspeed]

@43081j i do not agree i think we should force the users to upgrade anyway as latest nodejs version is 15 and lts is 14 so we are at the point where that is desire able to force them to use this as esm package even inside CJS via import()

[43081j]

i would love that to be the solution, the sooner people leave CJS behind, the better.

guess its @inikulin call to make, whether you make an ESM-only new major version or you support both (also in a major version tbf). people can always install the old one if they must, its not like the feature set will be changing anytime soon.

[elgs]

I hope we could import parse5 directly without webpack. This also will enable parse5 in the Deno world. That will be huge.

[RReverser]

I hope we could import parse5 directly without webpack. This also will enable parse5 in the Deno world. That will be huge.

Ah @inikulin said, no need to hope - feel free to make a PR :)