-
Notifications
You must be signed in to change notification settings - Fork 113
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
move to ESM (Chai 5) #310
move to ESM (Chai 5) #310
Conversation
@koddsson could you take a look at this please if you have time. |
I pushed some changes that fix the issue but there are some other issues that pop up. Mostly because there are still requires in the codebase which now error. |
@keithamus; I'm probably doing something wrong but |
Can confirm this, so could this be a upstream issue of the new chai 5 release? |
Maybe! I think writing upstream tests to demonstrate and prove to ourselves that there's a problem would be a great first step. |
I found ome upstream tests of the The file is 7 years old, but the tests seems valid to me, which could indicate that the error is in this plugin here. Maybe we can try and check if the chai v5 is working with another plugin to identify if it is an error in this plugin here or in the upstream Another more simplistic idea would be to create a empty sample plugin like in the unit tests to validate the plugin functionality with a real external plugin I could try to check this issue with the most up-to-date plugin (https://github.com/chaijs/chai-spies), but I need to find some time for this |
After tinkering around with all of this, I found that the return value of let customChai = chai.use(http)
customChai.request(/**/) If you use this returned variable, the tests are working, This looks like a upstream issue, but even with the given (and updated) unit test (https://github.com/chaijs/chai/blob/main/test/plugins.js), I wasn't able to figure out how to register a global I'm out of my knowledge here and I'm thinking about an upstream issue to resolve this - because now that v5 is released, it could be useful to have a working plugins API |
it is an issue in chai by moving to esm, we lost now it only mutates a fabricated we should track this in a chai issue as it will need discussion. in es modules, the old pattern isn't doable in most cases and/or is unnatural. so it may be that we have to introduce a new way of accessing extensions in 5.x (unfortunately does mean we have shipped a breaking change we weren't aware of! good catch) |
I know it is very bad manners to plug your own plugin as a solution to a problem, but some time ago I put together |
Hi, The build process is failing, but I don't know anything about this process, so I'm unable to fix this easily |
@Trickfilm400 can you please rebase against the main branch, I've updated CI to drop coveralls which looks like it's failing the build. |
If I want to run the (...)
I think the |
we should just drop i wonder if we should just ship the ES modules as-is and leave bundling up to consumers what do you think @keithamus? |
Sounds good to me 👍 |
@Trickfilm400 in that case i think you just need to (roughly) do the following:
this does mean it won't work in a browser anymore 🤔 (assuming it does now) if we do want it to work in a browser, we'd have to make an entrypoint that doesn't import node standard libraries. not too sure what we want to do about that yet |
I've updated it and made a note for the browser topic to use the v4 for now. If there is a solution in the future, it could be added again - personally, I will not use browser tests, I only need node tests It seems to me that everything is finished, so I will remove the draft state, but feel free to mention anything that needs to be done. |
/*! | ||
* Module dependencies. | ||
*/ | ||
import net from "net" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the formatting should really be consistent (i.e. missing semi here) but i wonder if we should just do a follow up prettier PR if we don't already have it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, setting up prettier would help a lot
We can create these follow-up PRs and then create the v5 release if this is finished (I didn't want to create all of this in this PR, as it would be too much I think)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good to me, though left a couple of questions/comments
@keithamus could you review too? this'd be a breaking change ofc, so need to take extra care reviewing if we need to update any docs etc
i think ill follow this PR up with some modernisations too (prettier, update some devDeps, etc)
the devDependencies are up-to-date, they got updated in the master branch recently I hope I didn't break anything with the rebase there while resolving the merge conflicts |
feat: update to latest chai version BREAKING-CHANGE: updated typescript interface due to incompatible export changes with esm (cannot export default and object in parallel)
fix: move type dependencies to devDependencies
Hi, @keithamus any news about this PR? The default branch got a few updates which would already be covered by this PR, which is a bit redundant work, so a merge would improve the situation Is it possible to restart the unit tests of the pipeline? The tests are failing because of some network timeout, but locally everything works just fine? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your hard work on this @Trickfilm400! LGTM 👍
"@semantic-release/changelog": "^6", | ||
"@semantic-release/commit-analyzer": "^12.0.0", | ||
"@semantic-release/git": "^10", | ||
"@semantic-release/npm": "^12.0.0", | ||
"@semantic-release/release-notes-generator": "^13.0.0", | ||
"chai": "4", | ||
"@types/chai": "^4.3.15", | ||
"@types/superagent": "^8.1.7", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upgrading from 4.3.0
to 5.1.1
broke our typechecking. Code like this
chai.request
.agent(this._server)
.post('/api/preview')
now fails with this error:
error TS2339: Property 'post' does not exist on type 'Agent'.
We think it's because @types/superagent
is now in devDependencies
, instead of dependencies
. I think it should be in dependencies
, because your package exports superagent
types publicly. Since the superagent types are part of your public types, any package which uses your types should also include the superagent
types that you export.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you open a standalone issue for this?
It sounds like you're right but I'll need to look when I'm not mobile and can test it out a bit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep! Thank you for building and maintaining this package!
Changes
import
/export
syntaxCurrent Issues
undefined
after chai.use and I don't know why (I appreciate any help :) )require
has a different behaviour than anyimport
syntax