chai 3.0.0 doesn't seem to be compatible with babel.
I updated babel to 5.5.3 and it fixed the issue.
Hey @moroshko thanks for the issue. I was just typing a reply and saw you closed it. Thanks!
Hey, I'm experiencing this error now on babel versions 5.6.x. I just upgraded from 5.6.4 to 5.6.14 and it doesn't fix the issue.
A reproducible case is
[1].should.have.length(1)
expect([1]).to.have.length(1)
I'll have a look at the source but I'm not sure I'll be able to fix this at first glance.
I keep thinking I'm doing something wrong here, as even things like expect([1].length === 1).to.be.true is failing
Even things like assert.strictEqual([1].length, 1) are failing :cry:
Sounds like that's probably not an issue with Chai. What errors are coming back? Can you compile the babel output and take a look at the source (or push it here).
So just compiling with babel, it works, but when I bundle it up with webpack, it fails. There is no point posting the whole webpack bundle (8352 lines), but I might making chai et al. external and see if I can get a smaller webpack file
Monkey patching the resulting bundle to look like this: https://gist.github.com/frederickfogerty/114d436f5184a1339bea works, but when I don't external chai, the resulting bundle gives me the error TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them
It looks like the same issue as #384
Yeah, the "use strict" problem is because chai _doesn't_ use strict mode, but your compiled output is forcing it into strict mode. The only real solution here is just... don't do that. I'd need to look at your whole build to point out where it's going wrong, but at any rate - this won't be a chai issue.
You might have some luck filing an issue with webpack - if it is setting a global "use strict", then it is the misbehaving party here.
It's babel causing the issue. This solves it https://babeljs.io/docs/advanced/transformers/other/strict/.
Is there any chance of chai moving to strict mode? Is the stuff chai does even possible with strict mode?
I don't think babel really causes the issue - because every file you pass into babel is "supposed" to run in its own context. I have no problem with browserify+babelify, because each file is wrapped in a function (){} - meaning the "use strict" directive is scoped to that module. Webpack (or perhaps your webpack config) is clearly not doing this, and instead concatenating the files unwrapped, or something.
As for Chai moving to strict mode - this is the one line stopping us from moving - but its reasonably important. We could look at ditching it and moving to strict mode - but I'm not entirely sure it is worth it, especially as its not really fixing the real issue here.
I think my real mistake was forgetting to remove node_modules from babel's reach. It was therefore transforming every module I required, including non-strict modules like chai. This is what browserify + babelify does by default (https://github.com/babel/babelify#why-arent-files-in-node_modules-being-transformed). Webpack works in the same way as Browserify, scoping everything in a function block, so the strict directives are scoped to each module.
{ test: /\.jsx?$/, exclude: /node_modules/, loader: 'babel' } was enough to stop babel transforming npm modules. I have this in my main webpack configuration, but karma uses a different config file, and I had forgotten to include it there.
I assume that line is for stack tracing? Using webpack I'm in the small minority who has no use for it (the stack traces don't work for webpack). It is definitely useful on my other projects where I'm not tied to webpack, though.
Anyway thanks for your help in resolving this!
Yeah, ssfi stands for start stack function indicator (I believe) and is a pointer to the current function in the stack - which gets passed to AssertionError so it can generate a stack trace with all of the chai internal stack omitted. This works anywhere V8 does (Chrome/Node/io.js/Android - see the v8 api in question). arguments.callee is used so that the function doesn't need to be passed in to the Assertion constructor every time. We could adopt "use strict" at the price of either losing ssfi or ensuring new Assertion is always called with the ssfi argument passed.
Please reopen this issue since it still stays on [email protected]
Hey @tresdin - as mentioned above, if you're using babel you shouldn't get it to convert your node modules. We don't currently support babel - however you're welcome to use it, but simply need to add `ignore: 'node_modules'`` to your config and things will work fine.
@keithamus Sorry for the misunderstanding. I don't use babel. I actually got this error when I installed chai via npm install chai.
@tresdin could you provide the install log which causes this error.
@keithamus The error doesn't occur on installation stage. Just like others, after a successful installation, I got this error with something like
expect(value).to.be.null
expect(value).to.be.undefined
should.exist(value)
@tresdin it looks like it might be worth filing a new issue with all of the relevant details, such as chai version, error logs, code to reproduce etc.
@keithamus I've filed this related issue #578. Please let me know if you need any other information.
Most helpful comment
I think my real mistake was forgetting to remove
node_modulesfrom babel's reach. It was therefore transforming every module I required, including non-strict modules likechai. This is what browserify + babelify does by default (https://github.com/babel/babelify#why-arent-files-in-node_modules-being-transformed). Webpack works in the same way as Browserify, scoping everything in a function block, so the strict directives are scoped to each module.{ test: /\.jsx?$/, exclude: /node_modules/, loader: 'babel' }was enough to stop babel transforming npm modules. I have this in my main webpack configuration, but karma uses a different config file, and I had forgotten to include it there.I assume that line is for stack tracing? Using webpack I'm in the small minority who has no use for it (the stack traces don't work for webpack). It is definitely useful on my other projects where I'm not tied to webpack, though.
Anyway thanks for your help in resolving this!