Open djackson-sykes opened 9 years ago
Thanks for reporting this.
I think fixing this may require changes in ember-cli proper, because I'm not seeing a hook that will let me postprocess the tests tree.
Depends on this: https://github.com/ember-cli/ember-cli/pull/2939
Once that's merged ember-browserify 0.5.0 should fix this.
I originally released this in 0.5.0 but hid it behind an environment variable in 0.6.0 because I don't want to break anybody who upgrades prematurely before ember-cli releases.
Thanks for being so quick with this!
I was about to enable this by default now that the ember-cli change shipped, but I found a bug.
This browserifies the app and test trees separately, which results in two copies of any module that's used in both. If you expected them to share state, you can have nasty bugs.
Working on a fix.
I haven't had a chance to fix this yet. The functionality is deployed and available for people who want it, but you need to turn it on by setting the environment variable BROWSERIFY_TESTS=true. The only caveat is the bug I mentioned above -- you get two independent copies of any module that you import from both app and tests.
What work needs to happen for this to land without the BROWSERIFY_TESTS
flag? This has bitten us a few times and it's potentially a blocking issue for our build environment.
Thanks!
To do this correctly we'd need to crawl both the app and vendor trees to gather dependencies and then call browserify only once, so that we don't get duplicate modules. Instead of running browserify separately for each tree.
:+1: for this. Browserify is the way forward, importing its modules is so nice but need it in tests.
this module is brilliant, i'm also very much hoping to be able to use this in my tests
@ef4: can I throw a PR at you to move BROWSERIFY_TESTS=true to a flag in environment.js
?
@ef4 pinging on this. We really would like first-class browserify support for Ember, and w/out this issue resolved we are having messy hacks to get our tests to work.
The ember-cli folks are working on a big internal refactor that will make ember-browserify-like functionality first-class.
@ef4 is there an issue I can follow on ember-cli for this?
Thanks for the workaround @xkb & @ef4.
I'm still running into issues unfortunately :( I've confirmed that L28 is getting executed.
I get the following error when trying to import sinon-chai
for ember-mocha
.
Error: Could not find module `npm:sinon-chai` imported from `my-project/tests/unit/controllers/delete-activity-test`
via
import sinonChai from "npm:sinon-chai";
As a temporary solution I'm importing the package indirectly through a dummy file in the app tree:
app/helpers/my-cool-npm-package.js
import myCoolNpmPackage from 'npm:my-cool-npm-package';
export default myCoolNpmPackage;
tests/unit/models/product.js
import myCoolNpmPackage from 'hello-world/helpers/my-cool-npm-package'
Works fine.
@jonnedeprez does this mean that my-cool-npm-package
is bundled into production builds? I have an npm-dependency that I need to use only in my tests.
@oliverwilkie You can manually exclude the package from production builds
// config/environment.js
module.exports = function(environment) {
var ENV = {
environment: environment,
baseURL: '/',
locationType: 'auto',
// ...
browserify: {
// your browserify options if you have any
ignores: [ ]
},
};
if (environment === 'production') {
ENV.browserify.ignores.push('my-cool-npm-package');
}
return ENV;
};
@stefanpenner curious as to why you closed this issue? Is there a linked issue that resolves this?
Yeah, as far as I know there is still a legit unresolved issue here. Trying to use ember-browserify from the tests tree is likely to troll people. The TESTS flag described above is not a full solution, just a different bad behavior that is preferable for some use cases.
any updates on this?
As an example:
From
app/router.js
works just fine, but in any test module (e.g.
tests/adapters/application.js
), the same line provokes an error:Environment:
Tests using
ember-cli-mocha
.