babelify + browserify-rails + react, Uncaught SyntaxError: 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 资产管道的问题。

完整代码库请参考https://github.com/sidazhou/react_rails_skeleton/tree/v0.0.1

components.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 日发表评论：}

尝试调试它的一个技巧是在您的源代码中添加注释 // require 或 // module.exports。这能解决吗？我们当然希望添加一个检测 es6（导入等）的适当修复程序。

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

重读您最初的帖子后，简单的解决方案是让 application.js 需要应用程序并启动它——只是不要使用 ES6 或其中的任何东西。这会让你到达你想要的地方，而不会乱七八糟。稍后，当您离开资产管道时（理想情况下），您将对编译拥有更多控制权，并且可以根据需要将其重构回主文件。但是为什么要解决这样一个小问题呢？

_{mockdeep^{（他打开了问题）}于 2015 年 12 月 18 日发表评论：}

是的，我们正在这样做。此时，我们刚刚在 application.js 中定义了几个全局变量。这只是一个令人惊讶的问题，如果您在 Chrome 或 Firefox 上进行测试，不一定会出现，因为它们都支持一堆 ES6 功能。

但是，为什么我们要退出资产管道？似乎它在预编译资产方面提供了一些相当可靠的价值。

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

因为资产管道正在成为一种反模式。 browserify-rails 存在的唯一原因是资产管道使 JavaScript 开发与当前的最佳实践相比保持了大约 -5 年左右的时间。虽然 browserify-rails 可以工作，但在某些时候，直接转到 browserify 或 webpack 会容易得多。

所以我的观点是，bro​​wserify-rails 最好从旧版 JavaScript 迁移到 CommonJS，然后跳出资产管道。

当然，每个人都可以随意使用它。将页面刷新连接到资产构建有一些好处。对于习惯使用 Rails 的 Ruby 开发人员来说，简单的“这就是它的工作方式”是有道理的。虽然使用 Procfile，但启动 webpack/browserify 并查看资产并根据需要重新编译并不难。所以我知道有各种各样的用例。

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

我换了雇主，现在直接使用 webpack（我喜欢这个 - 以前的工程师做出了这个选择，它工作得很好，我认为 browserify 也很好）。但我正在开发客户端 Web 应用程序，所以我们的后端通常是基于 Ruby 的 API，运行 Sinatra（使用 NodeJS 进行一些服务端渲染）。

我以前的雇主使用 browserify-rails 有一段时间了，但我认为他们已经跳出了资产管道。我不确定（我还没有机会与仍在从事该项目的人详细讨论它）。

其中一个问题是运行 browserify-rails 的时间更长，尤其是在低端 MacBook（Airs，较早的 13）上。使用 browserify-rails 2.x，我认为如果我们能够解决直接使用 Sprockets 而不是使用 Tilt 作为中介的问题（就像我们在 browserify-rails 1.x 上所做的那样），我们就有更好的机会保持高性能.事实上，Sprockets 缓存应该足够好，我们可以潜在地摆脱 browserify-incremental （这是缓存 browserify 构建以尝试保持性能 - 但现在在 2.x 中，我们在 Sprockets 中缓存并在 browserify 中缓存 -增量，这可能太复杂了）。

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