ruby-on-rails - babelify + browserify-rails + React，未捕获的语法错误 : Unexpected token import

Question

我正在使用 browserify-rails + babelify 在 React + Rails 项目中转译 jsx。

我很困惑为什么在components.js(这是react的挂载点)中需要//require('');来进行jsx转译去工作。

如果我删除注释行 //require('');，我会收到“SyntaxError: Unexpected token import”

目前我没有任何线索说明为什么一行注释会影响转译。我也很困惑这是否是react、babelify、browserify、browserify-rails或rails asset pipeline的问题。

请引用https://github.com/sidazhou/react_rails_skeleton/tree/v0.0.1完整的代码库

组件.js

// require(''); // somehow this is necessary, why?! Otherwise we get: "SyntaxError: Unexpected token import"
import React from 'react';
import ReactDOM from 'react-dom';
import Widgets from './components/Widgets.jsx';

ReactDOM.render( <Widgets />, document.getElementById('react_component') );

package.json

{
  "name": "react-sample",
  "dependencies": {
    "babel-preset-es2015": "^6.3.13",
    "babel-preset-react": "^6.3.13",
    "babelify": "^7.2.0",
    "browserify": "^12.0.1",
    "browserify-incremental": "^3.0.1",
    "history": "^1.13.1",
    "material-ui": "^0.13.4",
    "react": "^0.14.3",
    "react-dom": "^0.14.3",
    "react-router": "^1.0.2",
    "react-tap-event-plugin": "^0.2.1"
  },
  "engines": {
    "node": ">= 0.10"
  }
}

application.rb

config.browserify_rails.commandline_options = "-t [ babelify --presets [ es2015 react ] ]"

Answer 1

browserify-rails 有一个关于此的未决问题:

#124 transforms are only applied to files loaded with require() .

我试图通过引用一些我认为相关的 cymen 帖子来总结该主题(他是 browserify-rails 的作者)。

_{cymen 于 2015 年 12 月 10 日发表评论:}

One hack to try to debug it is to put a comment in your source that is // require or // module.exports. Does that solve it? We would of course want to add a proper fix of detecting es6 (import, etc).

_{cymen于 2015 年 12 月 18 日发表评论}

After rereading your initial post, the simple solution is to just have application.js require the application and kick it off -- just don't use ES6 or anything in it. That will get you where you want without a lot of messing around. Later on, when you're off the asset pipeline (ideally), you'll have more control over the compilation and can refactor it back into the main file if that is what you want. But why fight such a minor problem?

_{mockdeep^{(他打开了该问题)}于 2015 年 12 月 18 日发表评论:}

Yeah, we're doing that. We've just got a couple of globals defined in application.js at this point. It's just a surprising issue, and won't necessarily surface if you test on Chrome or Firefox, since they both support a bunch of ES6 features.

Why would we want to get off the asset pipeline, though? Seems like it provides some pretty solid value in terms of precompiling assets.

_{cymen 于 2015 年 12 月 18 日发表评论:}

Because the asset pipeline is becoming an anti-pattern. The only reason browserify-rails exists is because the asset pipeline is keeping JavaScript development about -5 or so years from current best practices. While browserify-rails will work, at a certain point, it's much easier to just go directly to browserify or webpack.

So my perspective is that browserify-rails is best to migrate from legacy JavaScript to CommonJS and then jump off the asset pipeline.

But everyone is free to use it as they see fit of course. There is some benefit to hooking up a page refresh to an asset build. For Ruby developers used to working with Rails, that simple "this is the way it works" makes sense. Although with a Procfile, it's not hard to kick off webpack/browserify watching the assets and recompiling as needed. So I understand there are a variety of use cases.

_{cymen 于 2015 年 12 月 18 日发表评论:}

I switched employers and am now using webpack directly (which I like -- a prior engineer made that choice and it's working fine, I think browserify is good too). But I'm working on client-side web applications so our backend is typically Ruby-based APIs running Sinatra (with NodeJS to do some service-side rendering).

My prior employer was using browserify-rails for a while but I think they have jumped off the asset pipeline. I'm not sure (I haven't had a chance yet to talk about it in detail with those still working on that project).

One of the issues was the time to run browserify-rails was taking longer particularly on lower end MacBooks (Airs, older 13). With browserify-rails 2.x, I think we have a much better chance of keeping performance high if we can work around the issues with using Sprockets directly instead of using Tilt as an intermediary (as we do on browserify-rails 1.x). In fact, the Sprockets caching should be good enough that we can potentially get rid of browserify-incremental (which is caching browserify builds to try to keep performance up -- but now with 2.x we have caching in Sprockets and caching in browserify-incremental which is likely too complex).

这是他对这个问题的最后评论(3 个月前)。因此，您已经拥有的解决方法是目前可用的最佳解决方案(直到有人在 browserify-rails 中实现 ES6 检测)。