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
ES module conversion PoC #1498
ES module conversion PoC #1498
Conversation
The changes made in chaijs#1334 incorrectly used an arrow function and as this isn't supported on IE 11 it causes a SyntaxError to be thrown when loading chai.
Bumps [codecov](https://github.com/codecov/codecov-node) from 3.1.0 to 3.7.1. - [Release notes](https://github.com/codecov/codecov-node/releases) - [Changelog](https://github.com/codecov/codecov-node/blob/master/CHANGELOG.md) - [Commits](codecov/codecov-node@v3.1.0...v3.7.1) --- updated-dependencies: - dependency-name: codecov dependency-type: direct:development ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* 4.x.x: Fix link to commit logs on GitHub As there is no `master` branch, the link returned a 404. * Update History.md Co-authored-by: Andre Meyering <info@andremeyering.de> Co-authored-by: Keith Cirkel <keithamus@users.noreply.github.com>
Bumps [socket.io-parser](https://github.com/socketio/socket.io-parser) from 4.0.4 to 4.0.5. - [Release notes](https://github.com/socketio/socket.io-parser/releases) - [Changelog](https://github.com/socketio/socket.io-parser/blob/main/CHANGELOG.md) - [Commits](socketio/socket.io-parser@4.0.4...4.0.5) --- updated-dependencies: - dependency-name: socket.io-parser dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
previously it was incorrectly labeled as `objDisplay(obj: object): void` in `@types/chai`.
This moves all of the sources to be ES modules rather than CommonJS. In order to produce the entrypoints, we use esbuild as a bundler (and as a transpiler in a way). Due to the fact that some dependencies are written in CommonJS, we actually use esbuild to create _two_ bundles: a CommonJS bundle, and an ES module bundle. Otherwise, someone importing the raw source would inevitably end up trying to import a CommonJS module somewhere down the tree, which would not work in browsers natively.
|
@keithamus did you ever get chance to take a peek at this? would be good to get some thoughts giving chai a real es module would be so useful |
|
Thanks for the reminder! I’ll give this a closer look tomorrow ❤️ |
|
@43081j I've published this as |
|
@keithamus what a guy :D thanks so much for spending some time to review it. this'll be such a huge step forward for the library IMO. many of us have moved to ES packages in recent times, but there's no equally mature/stable assertion library yet. so we've ended up with bundled copies of chai, or very new (and experimental) libraries. it'll be great to be able to stick with chai. |
|
Hopefully by dropping older engines and CommonJS we can ensure that Chai is able to evolve with the rest of the ecosystem! |
|
@keithamus just saw your post about this. we haven't actually dropped commonjs yet. you can still require() the alpha. if the plan is to not support it, we can halve the npm package size by dropping the commonjs bundle i left in here 👀 do you want me to do that in a separate PR? |
|
@43081j I understand you created the cjs files in this PR, but yes, I think let's make a clean break from CommonJS to ease releasing. If you're happy to make the separate PR I'm happy to accept it 😄 |
|
Sure happy to do that. Right now it means there's two bundles basically, double the package size because of needing esm and cjs Would love to drop the cjs one. We still need to bundle because of cjs dependencies but at least it'll get rid of one of the two bundles |
|
Right. I'd also like to convert the cjs deps we have, like loupe. |
|
Yup I agree End goal should be a purely esm dependency tree. So we don't have to bundle at all and can ship the sources as is Maybe an issue to track any incompatible dependencies would be good. There's possibly a few |
I'm sure there's plenty of other things to take into account, tests to add (such that we test both CJS/ESM equally) and maybe some problems in this I missed - however, here's a PoC of converting the codebase to ESM.
As the commit says, it uses esbuild under the hood to create two bundled entrypoints:
chai.js- ESMchai.cjs- CommonJSTwo because there are still dependencies written in CommonJS, which invalidates the ESM-only tree (meaning you wouldn't be able to use it natively in a browser). Bundling them means we can leave it up to esbuild to figure the dependencies out and ship pure ESM.
If you ever want this or feel like picking it up, let me know, i can probably find a little time to pair on it some way.
The diff's a little funky because I first caught up from 4.x.x into my 5.x.x-based branch, while the current 5.x.x branch is actually out of date (and I fixed the conflicts there).
Also, it'd probably break the
usefunction externally (haven't tried it). has no use anymore internally but who knows what third party packages are depending on it. tried to imitate it with some mock exports object but haven't really tested it.i have tested it with a few chai plugins to see if
useworks, and all seems fine.