Skip to content
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

Open
achingbrain opened this issue Oct 3, 2019 · 1 comment
Open

Order of chai.use breaks .has.property target change #1298

achingbrain opened this issue Oct 3, 2019 · 1 comment

Comments

@achingbrain
Copy link

achingbrain commented Oct 3, 2019

Running the following code:

const chai = require('chai')
chai.use(require('dirty-chai'))
chai.use(require('chai-as-promised'))

chai.expect({a: 1}).to.have.property('a').that.is.a('number') // copied from the docs

results in this error:

$ node test.js 

/path/to/project/node_modules/chai/lib/chai/assertion.js:141
      throw new AssertionError(msg, {
      ^
AssertionError: expected { a: 1 } to be a number
    at Object.<anonymous> (/path/to/project/test.js:5:51)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
...

However swapping the order of the chai.use(...) statements around or just using one of them makes it pass:

// fails
chai.use(require('dirty-chai'))
chai.use(require('chai-as-promised'))

// passes
chai.use(require('chai-as-promised'))
chai.use(require('dirty-chai'))

// passes
chai.use(require('chai-as-promised'))
// chai.use(require('dirty-chai'))

// passes
// chai.use(require('chai-as-promised'))
chai.use(require('dirty-chai'))

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 you chai.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).

achingbrain added a commit to ipfs/js-ipfs that referenced this issue Oct 3, 2019
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 <alan.shaw@protocol.ai>

* 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
@rgroothuijsen
Copy link
Contributor

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 you chai.use things shouldn't matter?

I'd think so as well, though looking at the code of chai-as-promised and dirty-chai, I'm not so certain. They each have their own way of modifying Chai, so interactions certainly are possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants