Adding plugins via .babelrc (and transpiling recursively for referenced modules)?

[gnl]

I've been using this for a few weeks now with the Hydrogen plugin for Atom and it's working great, but when trying to add a babel plugin in .babelrc jp-babel doesn't seem to find it:

{ "plugins": ["syntax-flow"] }

I tried both project local and global plugin installation, as well as putting .babelrc in the project root and $HOME, doesn't make a difference.

Am I missing something here, any way to make this work?

[n-riesco]

At the moment, jp-babel ignores .babelrc. I could add a command line flag, e.g.

jp-babel --jp-babelrc=path/to/.babelrc

Would that work for you?

In the meantime, you can work around this issue by editing this line in the nel.js file.

[gnl]

Thanks! Is it possible to set that flag by default in a config file somewhere? Not sure I can configure the arguments passed by Hydrogen.

As for the workaround - that sounds like it should work, but I just realized it's only part of the problem - I'd also need a way to make jp-babel run babel-node instead of node. Possible?

For reference:

I'm trying to run some code that imports another module, which has Flow type annotations and type exports. When jp-babel is run normally with node, it craps out with this:

import Units from './data/Units' SyntaxError: Unexpected reserved word at exports.runInThisContext (vm.js:53:16) at Module._compile (module.js:414:25) at Object.Module._extensions..js (module.js:442:10) at Module.load (module.js:356:32) at Function.Module._load (module.js:311:12) at Module.require (module.js:366:17) at require (module.js:385:17) at evalmachine.<anonymous>:3:14 at Object.exports.runInThisContext (vm.js:54:17) at run ([eval]:192:19)

Which is exactly what node returns when run directly on the babel-transpiled code - I'm guessing the referenced modules aren't transpiled recursively, because when I eval them directly with node after transpiling with babel it works just fine.

With babel-node it all works like a charm.

P.S. FYI - if someone else stumbles onto this - the required babel plugins are: "plugins": ["syntax-flow", "transform-flow-strip-types"]

[n-riesco]

On 21/12/15 18:11, Georgi Lipov wrote:

Thanks! Is it possible to set that flag by default in a config file somewhere?

There is no need to pass arguments to Hydrogen, the installation of the jp-babel kernel remembers the command flags used in the installation; e.g.:

jp-babel --jp-install=local --jp-babelrc=/path/to/.babelrc

As for the workaround - that sounds like it should work, but I just realized it's only part of the problem - I'd also need a way to make jp-babel run babel-node instead of node. Possible?

I haven't tested it yet, but I think you could edit this line:

https://github.com/n-riesco/jp-babel/blob/master/lib/nel.js#L64

and replace it with:

node: "/path/to/babel-node",

If it works, please, could you report back your experience with it?

For reference:

I'm trying to run some code that imports another module, which has Flow type annotations and type exports. When jp-babel is run normally with node, it craps out with this:

SyntaxError: Unexpected reserved word at exports.runInThisContext (vm.js:53:16) at Module._compile (module.js:414:25) at Object.Module._extensions..js (module.js:442:10) at Module.load (module.js:356:32) at Function.Module._load (module.js:311:12) at Module.require (module.js:366:17) at require (module.js:385:17) at evalmachine.:3:14 at Object.exports.runInThisContext (vm.js:54:17) at run ([eval]:192:19) |

I've had a similar problem with jp-coffeescript. It fails because Babel is not registered with the require function. I think using babel-node should fix the problem.

Which is exactly what node returns when run directly on the babel-transpiled code - I'm guessing the referenced modules aren't transpiled recursively, because when I eval them directly with node after transpiling with babel it works just fine.

With babel-node it all works like a charm.

If babel-node works for you, I will update jp-babel to use it.

[gnl]

After setting the babel-node path in the var you pointed to and restarting the kernel, every time I eval something it just hangs, no response for minutes until I kill it.

I'm guessing babel-node isn't quite a drop-in replacement for node, for example with node I can do: echo 'var a = 2; a'|node -p

and it works fine, with babel-node it works like this: babel-node -p 'var a = 2; a'

How are you passing the code-to-eval to node, is it like this or something similar? If yes, maybe just passing stdin as an argument to babel-node -p would do it.

For reference, the modified parts of nel.js now look like this:

var transformOptions = {
    presets: ["es2015-node", "react"],
};

var paths = {
    node: "/usr/local/lib/node_modules/babel-cli/bin/babel-node.js",
    thisFile: fs.realpathSync(module.filename),
};

[n-riesco]

Now, the problem seems to be that babel-node fails to execute nel_server.js:

$ babel-node --eval nel_server.js 

/home/user/node_modules/babel-cli/lib/_babel-node.js:102
  return _vm2["default"].runInThisContext(code, {
                         ^
ReferenceError: nel_server is not defined
    at [object Object]:1:1
    at _eval (/home/user/node_modules/babel-cli/lib/_babel-node.js:102:26)
    at Object.<anonymous> (/home/user/node_modules/babel-cli/lib/_babel-node.js:122:16)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:902:3

Without looking into this error deeper, I don't understand what the cause is.

---

And to answer to your last question, the function that transpiles the code is here and here is where the transpile function gets called.

[gnl]

Got it, I'll try to look into it when I have more time.

[n-riesco]

Thank you for looking into this.

[gnl]

I got this working now, it ain't pretty, but it gets the job done:

fb1539046d399b145ca8266c692cadfafb0198b7

For some reason which I haven't quite figured out yet, both the babel-node --presets arguments and the babel transpilation options are required for things to work. I would have thought no extra transpilation step would be necessary with babel-node, even tried bypassing it, but it's needed.

The general problem was that babel-node runs a wrapper script that's trying to handle some common node arguments (apparently in an attempt to work as a drop-in replacement) and then calls the actual babel-node code. Since we don't seem to be needing any of those particular arguments in jp-babel, I bypassed the wrapper, called the actual babel-node directly and ta-daa.

Not sending a pull request yet, cause this is ugly and hardcoded, but if you let me know how you'd like it integrated, maybe I can make it presentable. Unless this is enough for you to shake a proper fix out of your sleeve quickly.

I think what you suggested earlier, moving to babel-node altogether, is a good idea, I'd just like to figure out why the extra transpilation step is still necessary.

[jmatsushita]

Would love to see jp-babel automatically pickup .babelrc too!

[n-riesco]

Closed via #7