systemjs-plugin-babel fails to work properly on v6.2.0 but works fine on v6.1.0.
I'm not very familiar with the internals of systemjs-plugin-babel so I can't provide any detailed info.
Refer to jspm/jspm-cli#1882 for details about the symptom.
@panicbit do you have access to other systems such as debian / ubuntu / or osx to see if this failure is happening there too.
Can you describe a bit more in depth how to reproduce the failure or share a project that can reliably fail
@TheAlphaNerd I don't but it seems to work for @OrKoN on Ubuntu 16.04, Node 6.2.0, Npm 3.9.5
The failure happens when trying to bundle a project using babel.
To replicate it install jspm@beta, download this skeleton project and run jspm bundle src/app.js in the project root.
The error also happens on my system with nodejs compiled from the latest tarball (6.2.1), so it doesn't look like this is a packing issue in Arch. Maybe there is some sort of incompatability with one of nodejs' dependencies?
This even happens on a fresh Arch system.
Also, for some reason only the binary 6.1.0 Arch package seems to work for me, but a 6.1.0 manually build from source does not...
I can observe the same behavior on Arch
$ node --version
v6.2.1
$ jspm --version
0.17.0-beta.18
Same versions as above works on OSX.
Tested running using latest node nightly on Arch works.
$ node --version
v7.0.0-nightly20160610624734e640
I am running into a similar issue:
Platform: Arch Linux, x86_64
Version: 6.2.2
Same error.
Arch Linux, x86_64, node 6.3.0, npm 3.10.5, jspm 0.17.0-beta.22.
With v7.0.0-nightly20160717c897d0ba71 I get this error:
err Error: Error loading app/app.js: load hook should return a string, a { code, map } object, or nothing/null
Update: If I put some actual code into the _app.js_-file in the demo it works with nightly.
I get the same symptoms, pretty much exactly as @panicbit describes it.
Downgrading to 6.1.0 works, but only if I install it from the binary, which I got from the arch linux archive
It is worth noting that I also had to downgrade to http-parser 2.7.0
I have the same issue on Arch Linux x86_64 too.
$ node -v
v6.3.1
$ npm -v
3.10.5
$ jspm -v
0.17.0-beta.22
Tested the demo project that @panicbit linked. The issue is easily reproducible on Arch with LTS kernel 4.4.15-1-lts:
node v6.3.1
npm 3.10.5
jspm 0.17.0-beta.25
Trying the same on a Debian Jessie with kernel 3.16.0-4 has no problems:
node v6.3.1
npm 3.10.3
jspm 0.17.0-beta.25
Ok, after a bit of debugging I've isolated the problem down to a bug in the module export system. Let's take a look at node_modules/babel-runtime/core-js/get-iterator.js:
module.exports = { "default": require("core-js/library/fn/get-iterator"), __esModule: true };
If we console.log the exported module we get { default: 0, __esModule: true } instead of the expected { default: [Function], __esModule: true } and as the consumer expects a function it errors when it invokes the number 0. This issue can be reproduced only if we name the property default and only if this is the first property in the exported object. Also note that if we just import the "core-js/library/fn/get-iterator" function it is imported properly. It becomes a 0 only when we export it as a property named default. Also note that I am not able to reproduce this in a simpler context so there must be another catalyst in the JSPM/Arch context affecting the issue.
In order to work around the issue and make the JSPM build pass you need to edit the two files (where JSPM is installed):
node_modules/babel-runtime/core-js/get-iterator.jsnode_modules/babel-runtime/core-js/json/stringify.jsJust move the default property at the end of the exports and the JSPM bundle will succeed. Note that the babel files that need to be modified are dependencies of the systemjs builder as part of the JSPM NPM package and are not to be confused with the plugin-babel in the jspm_packages folder.
Getting this same issue, workaround above works for me.
Arch Linux, x86_64, node 6.5.0, npm 3.10.6, jspm 0.17.0-beta.28.
I've updated to node 6.6.0, npm 3.10.7 and using jspm 0.17.0-beta.22, still on Arch Linux and my issues are gone.
I confirm, updating to node 6.6.0, npm 3.10.7 fixes this issue.
I can confirm this working on node 6.5.0, jspm 0.17.0-beta.28.