Not working with WebPack 2 beta

[sudsy]

./~/inject-loader!../src/pages/calculators/module-ray-tracer/calc-module-ray-tracer/turboSimJobManager.js
Module parse failed: C:\Users\sudsy\Development\gen3\PVL.Content\tests\node_modules\inject-loader\index.js!C:\Users\sudsy\Development\gen3\PVL.Content\src\pages\calculators\module-ray-tracer\calc-module-ray-tracer\turboSimJobManager.js 'import' and 'export' may only appear at the top level (4:0)
You may need an appropriate loader to handle this file type.
| var module = {exports: {}};
| var exports = module.exports;
| import {Observable} from 'rxjs/Observable';
| import auth from "authentication";
| import connMgr from "modules/connection-manager/connection-manager";
@ ./unit-mocha/modules/SimJobManager/testTurboSimJobManager.js 3:0-110
@ ./unit-mocha/modules/SimJobManager/testTurboSimJobManager.js
@ multi main

[plasticine]

@sudsy Hey there, I think what is happening here is that you are perhaps trying to inject before you’ve transformed the code. This would mean that is you are writing code using es6 modules (as above), they are going to be moved inside the closure for injection — which as the error is indicating — is not allowed.

Please try running inject after and code transformations (e.g babel), and feel free to re-open if you’re still having issues. 👍

[sudsy]

Hi Justin,

I'm not using babel at all. I'm using the native es6 module support from
Webpack 2.

I can't see how I can run the loader after the native transformations.

Sudsy

On Sat, 3 Sep 2016, 14:30 Justin Morris notifications@github.com wrote:

Closed #14 #14.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#14 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABjlh2BotsEbVmV8iuIsTu-KjRo-e7h7ks5qmPfbgaJpZM4JmICa
.

[plasticine]

I'm not using babel at all. I'm using the native es6 module support from
Webpack 2.

I can't see how I can run the loader after the native transformations.

Ahh, OK — I see. I’m not sure if I can support that use-case, at the moment only injecting CJS deps is supported. I’ll try and see if I can come up with an alternative.

[stayman]

@plasticine is there any movement on this use case, I'd also be interested in this, and would be happy to collaborate on a PR if we could figure out a strategy that works.

[plasticine]

@stayman No movement as such — no.

To be honest I can’t see that it’s possible to support this use-case. The whole premise of inject-loader is to wrap the module-under-test in a closure in order to inject dependencies — something that is in conflict with es6 style modules where imports and exports must be at the top level.

For code under test I would suggest that you transform these imports to CJS style in order to use inject-loader, this should be pretty straight forward to isolate this transformation to only apply in test environments using babel-env or similar.

Most definitely open to other ideas, but as far as I can see that’s kinda where we’re at...