-
-
Notifications
You must be signed in to change notification settings - Fork 698
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
Order of chai.use
breaks .has.property
target change
#1298
Comments
achingbrain
added a commit
to ipfs/js-ipfs
that referenced
this issue
Oct 3, 2019
Workaround for chaijs/chai#1298
achingbrain
added a commit
to ipfs-inactive/interface-js-ipfs-core
that referenced
this issue
Oct 4, 2019
Workaround for chaijs/chai#1298 The order in which plugins are applied to chai is important and can break tests in other modules that run the tests from this one.
achingbrain
added a commit
to ipfs-inactive/js-ipfs-http-client
that referenced
this issue
Oct 4, 2019
This is to work around chaijs/chai#1298 Fundamentally we cannot pull in chai and add plugins to it without being careful of the order of those plugins as it's a singleton. All we're really interested in is the `expect` function to just get the preconfigured one from the interface tests.
achingbrain
added a commit
to ipfs-inactive/js-ipfs-http-client
that referenced
this issue
Oct 4, 2019
This is to work around chaijs/chai#1298 Fundamentally we cannot pull in chai and add plugins to it without being careful of the order of those plugins as it's a singleton. All we're really interested in is the `expect` function to just get the preconfigured one from the interface tests.
achingbrain
added a commit
to ipfs/js-ipfs
that referenced
this issue
Oct 4, 2019
Fundamentally we cannot pull in chai and add plugins to it without being careful of the order of those plugins as it's a singleton. All we're really interested in is the `expect` function to just get the preconfigured one from the interface tests.
achingbrain
added a commit
to ipfs/js-ipfs
that referenced
this issue
Oct 4, 2019
This is to work around chaijs/chai#1298 Fundamentally we cannot pull in chai and add plugins to it without being careful of the order of those plugins as it's a singleton. All we're really interested in is the `expect` function to just get the preconfigured one from the interface tests.
achingbrain
added a commit
to ipfs/js-ipfs
that referenced
this issue
Oct 4, 2019
This is to work around chaijs/chai#1298 Fundamentally we cannot pull in chai and add plugins to it without being careful of the order of those plugins as it's a singleton. All we're really interested in is the `expect` function to just get the preconfigured one from the interface tests.
achingbrain
pushed a commit
to ipfs/js-ipfs
that referenced
this issue
Oct 6, 2019
* feat: config profile * fix: increase command count * feat: ipfs init --profile option * chore: update dependencies License: MIT Signed-off-by: Alan Shaw <[email protected]> * fix: make sure default-config still works * chore: add http api tests * chore: address PR comments * chore: fix linting * test: let internals of config profiles be internal * chore: add test for listing profiles * chore: turn profile list into list outside of core * chore: expose profile list over http * fix: use chai exported from interface tests Workaround for chaijs/chai#1298 * chore: fix linting * chore: update deps and make keys agree with spec * chore: update interface tests * chore: udpate test skips/includes * chore: fix up interface tests
I'd think so as well, though looking at the code of |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Running the following code:
results in this error:
However swapping the order of the
chai.use(...)
statements around or just using one of them makes it pass:I'm not really sure if this is a problem with
chai
,chai-as-promised
,dirty-chai
or a combination of all three but presumably the order in which youchai.use
things shouldn't matter?Because
chai
is a singleton this can also happen across multiple files and even multiple modules in the same project if they all depend on the same version (as seen in #1213).The text was updated successfully, but these errors were encountered: