babelify + browserify-rails + react,Uncaught SyntaxError:意外的令牌导入

Question

我正在使用 browserify-rails + babelify在react + rails项目中转换jsx.

我很困惑为什么// require('');需要components.js(这是反应的安装点)让jsx转换工作.

如果我删除注释行 // require('');,我会得到"SyntaxError:Unexpected token import"

目前我没有任何线索,为什么一行评论会影响转换.我也很困惑,如果这是一个反应,或babelify,或浏览器,或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 转换仅适用于加载了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 会容易得多。

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

当然，每个人都可以按照自己认为合适的方式自由使用它。将页面刷新连接到资产构建有一些好处。对于习惯使用 Rails 的 Ruby 开发人员来说，简单的“这就是它的工作方式”是有意义的。尽管使用 Procfile，但启动 webpack/browserify 来监视资产并根据需要重新编译并不困难。所以我知道有各种各样的用例。

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

我换了雇主，现在直接使用 webpack（我喜欢这一点——之前的工程师做出了这个选择，而且工作正常，我认为 browserify 也很好）。但我正在开发客户端 Web 应用程序，因此我们的后端通常是运行 Sinatra 的基于 Ruby 的 API（使用 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 中缓存 -增量可能太复杂）。

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