Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to get reify to work with other tools (e.g. babel, etc) #31

Closed
brainkim opened this issue Jun 10, 2016 · 8 comments
Closed

How to get reify to work with other tools (e.g. babel, etc) #31

brainkim opened this issue Jun 10, 2016 · 8 comments
Assignees
Labels

Comments

@brainkim
Copy link

brainkim commented Jun 10, 2016

Hi!

I'm trying to place reify in the context of other tools, i.e. understand what it replaces, what it works with. Specifically, I'm wondering about it's relationship to babel. I've been trying to make reify and babel work nicely together, but it seems like you can't configure babel to accept non-top level imports. It throws the following error no matter which permutation of plugins and configuration options I use:

/Users/briankim/Projects/react-walk/node_modules/babel-core/lib/transformation/file/index.js:591
      throw err;
      ^

SyntaxError: /Users/briankim/Projects/react-walk/example.js: 'import' and 'export' may only appear at the top level (33:2)
  31 | 
  32 | if (false) {
> 33 |   import React from 'react';
     |   ^
  34 | }
  35 | 
    at Parser.pp.raise (/Users/briankim/Projects/react-walk/node_modules/babylon/lib/parser/location.js:22:13)
    at Parser.pp.parseStatement (/Users/briankim/Projects/react-walk/node_modules/babylon/lib/parser/statement.js:134:16)
    at Parser.parseStatement (/Users/briankim/Projects/react-walk/node_modules/babylon/lib/plugins/flow.js:30:22)
    at Parser.pp.parseBlockBody (/Users/briankim/Projects/react-walk/node_modules/babylon/lib/parser/statement.js:529:21)
    at Parser.pp.parseBlock (/Users/briankim/Projects/react-walk/node_modules/babylon/lib/parser/statement.js:510:8)
    at Parser.pp.parseStatement (/Users/briankim/Projects/react-walk/node_modules/babylon/lib/parser/statement.js:127:19)
    at Parser.parseStatement (/Users/briankim/Projects/react-walk/node_modules/babylon/lib/plugins/flow.js:30:22)
    at Parser.pp.parseIfStatement (/Users/briankim/Projects/react-walk/node_modules/babylon/lib/parser/statement.js:314:26)
    at Parser.pp.parseStatement (/Users/briankim/Projects/react-walk/node_modules/babylon/lib/parser/statement.js:105:19)
    at Parser.parseStatement (/Users/briankim/Projects/react-walk/node_modules/babylon/lib/plugins/flow.js:30:22)

Here's a commit showing my failed attempts at getting reify and babel to work together

My question is, if we want to use reify-style import and export, but also want to use other es6 things, what's the best way to configure our projects? Is reify orthogonal to babel? Can they work together? Does reify plan to become a full-fledged transpiler?

@benjamn
Copy link
Owner

benjamn commented Jun 10, 2016

These are good questions, and I admit I don't know all the answers, but here's how https://github.com/meteor/babel gets around the parsing restrictions on nested import statements. Note especially parserOptions.allowImportExportEverywhere and require("babel-core").transformFromAst.

@benjamn
Copy link
Owner

benjamn commented Jun 10, 2016

Also, while I don't plan to make reify a full transpiler, I do hope to write a proper Babel plugin for it.

@brainkim
Copy link
Author

brainkim commented Jun 10, 2016

🤔 🤔 🤔 🤔 🤔 🤔

This seems like an issue to log against either https://github.com/babel/babel or https://github.com/babel/babylon, which I think is the parser which throws this error.

Can we make this babel error-throwing behavior configurable just like http://babeljs.io/docs/plugins/check-es2015-constants/?

@hzoo
Copy link

hzoo commented Jun 10, 2016

Like @benjamn already mentioned, you just need to pass in allowImportExportEverywhere to the parser. However it seems that at the moment you can't do so through .babelrc - so there's babel/babel#3503. Otherwise the commonjs transform could add another option that turns on the parser option @loganfsmyth

@brainkim
Copy link
Author

brainkim commented Jun 10, 2016

@hzoo Thanks for the additional info. I was trying to see if I could quickly work reify into some code I was writing and I saw this
screen shot 2016-06-10 at 4 05 55 pm
in the transform-es2015-modules-commonjs docs and thought this error behavior was configurable based on the "loose" option, which does not seem to be true.

@hzoo
Copy link

hzoo commented Jun 10, 2016

Oh you're right.. then I think it's just not doing that correctly atm, or that changed since it wasn't that in babel 5.x. Now it would be nice if I remembered why I added that .. http://henryzoo.com/babel.github.io/docs/advanced/loose/#es6-modules

@loganfsmyth
Copy link

Those docs are likely outdated. I wouldn't expect loose: true to allow that since I don't think our transformation logic is really set up to handle it anyway.

@benjamn
Copy link
Owner

benjamn commented Mar 16, 2017

Sorry for the long wait on this. I recently created a Babel plugin that wraps the Reify compiler, which should make it easier to include Reify in your Babel plugins.

Note that this plugin is compatible with Babel's CommonJS modules plugin, and I even recommend using both, so that the CommonJS plugin can take care of any top-level import declarations added by other Babel plugins. Of course you'll want to make sure Reify is running before the CommonJS plugin, or you won't see any benefits.

Also please note that installing the runtime is non-trivial if you're using a tool like Webpack or Browserify, for the reasons described in README.md. Currently Node and Meteor are my primary support targets, but I hope the requirements I've outlined there will eventually influence other module runtimes. In short, Module.prototype is a very useful object!

@benjamn benjamn self-assigned this Mar 16, 2017
@jdalton jdalton closed this as completed May 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants