I was trying to use require Chai while using Mocha/Karma.
ERROR [framework.browserify]: bundle error
ERROR [framework.browserify]: Error: Cannot find module './chai/config' from 'C:\foldernode_modules\chai'
The error repeats until './chai/interface/expect'
I'm using Windows 7, it worked when I switched to version 3.5.0.
@laistomazz Thanks for the issue. Any chance you could create a small, standalone repo demonstrating the error?
Here it is:
https://github.com/laistomazz/chaiIssue
I tested it on a MacOS right now and the error is the same.
I hope it helps :)
I'm seeing a similar error on my repo when trying to update to v4.0.0.
https://github.com/kt3k/spn/pull/63
build on circle-ci
https://circleci.com/gh/kt3k/spn/345
This seems to be the problem of "browser" field in package.json, imported by #875.
Passing --no-browser-field to browserify option may temporarily resolve the problem. (But it may have unexpected side effects)
I personally disagree that this package should have browser field in package.json. It may cause problem like this and #981.
Hi @laistomazz, thanks for your issue and thanks everyone for your help.
I have just read the browser field spec and I agree with @hakatashi.
Apparently it's goal is to replace the entry-point for when bundling a module, but since webpack and browserify will already go through all the requires recursively, I think we don't need that, we could just let our users bundle it the way they find to be better.
The ones wanting to use Chai in the browser can still link to the chai.js file in the root of this repo.
I've reviewed the browser field spec as well, along with @laistomazz's sample repo. I agree with the conclusions drawn in this post:
browser field to package.json in #875.browser field isn't intended to point to a pre-bundled file; instead, it's intended to provide guidance to bundlers on how to bundle modules that have different dependencies based on server or browser environments.browser field in Chai is instructing bundlers such as Browserify and Webpack to use our browserified bundle ./chai.js as their entry point.I think the thing to do in the short-term is revert #875 and release 4.0.1 as bug fix release. In the long term, if the problem that led to #875 is still a problem, it may be possible to use the browser field in a different way to resolve that problem with Buffer. But that's for a different PR.
Sorry, this was down to me. Should have known better. Let's release a 4.0.1 without the offending field 馃槃
Most helpful comment
I've reviewed the
browser fieldspec as well, along with @laistomazz's sample repo. I agree with the conclusions drawn in this post:browserfield topackage.jsonin #875.browserfield isn't intended to point to a pre-bundled file; instead, it's intended to provide guidance to bundlers on how to bundle modules that have different dependencies based on server or browser environments.browserfield in Chai is instructing bundlers such as Browserify and Webpack to use our browserified bundle./chai.jsas their entry point.I think the thing to do in the short-term is revert #875 and release 4.0.1 as bug fix release. In the long term, if the problem that led to #875 is still a problem, it may be possible to use the
browserfield in a different way to resolve that problem with Buffer. But that's for a different PR.