Babelify + browsify-rails + реагировать, Не использовать SyntaxError: Неожиданный импорт маркера

Я использую browserify-rails + babelify, чтобы перетащить jsx в проект реакции + rails.

Я очень озадачен, почему // require(''); необходим в components.js (который является точкой реагирования) для работы трансляции jsx.

Если я удалю строку комментария // require('');, я бы получил "SyntaxError: Неожиданный импорт маркера"

В настоящее время у меня нет указаний, так как почему строка комментария влияет на транспиляцию. Я также озадачен, если это проблема реагирования, или обновления, или браузера, или браузера-рельсы, или рельсов.

Обратитесь к 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 ] ]"

Ответ 1

Для browserify-rails существует открытая проблема:

# 124 преобразования применяются только к файлам, загруженным с помощью require().

Я пытаюсь суммировать поток, цитируя некоторые столбцы, которые, на мой взгляд, являются релевантными (он автор браузера-рельсов).

_{cymen прокомментировал 10 декабря 2015 года:}

Один взломать, чтобы попытаться отладить его, - поставить комментарий в свой источник, который // require или // module.exports. Решает ли это? Разумеется, мы хотели бы добавить правильное исправление обнаружения es6 (импорт и т.д.).

_{cymen прокомментировал 18 декабря 2015 г.}

После перезаписи вашего начального сообщения простое решение состоит в том, чтобы просто потребовать приложения application.js и выключить его - просто не используйте ES6 или что-нибудь в нем. Это приведет вас туда, где вы хотите, без большого беспорядка. Позже, когда вы отключитесь от конвейера активов (в идеале), вы получите больше контроля над компиляцией и сможете реорганизовать его обратно в основной файл, если это то, что вы хотите. Но зачем бороться с такой незначительной проблемой?

_{mockdeep ^{(он открыл проблему)} прокомментировал 18 декабря 2015 года:}

Да, мы это делаем. На данный момент мы только что получили пару глобалов, определенных в application.js. Это просто удивительная проблема, и она не обязательно будет отображаться, если вы протестируете Chrome или Firefox, так как они поддерживают множество функций ES6.

Почему мы хотим выйти из конвейера активов? Похоже, что он обеспечивает довольно солидную ценность с точки зрения прекомпиляции активов.

_{cymen прокомментировал 18 декабря 2015 года:}

Поскольку конвейер активов становится анти-шаблоном. Единственная причина, по которой существует браузер-рельсы, заключается в том, что конвейер активов поддерживает разработку JavaScript около -5 или около того лет от существующих лучших практик. Хотя Browsify-rails будут работать, в какой-то момент гораздо проще просто перейти непосредственно к браузеру или веб-пакету.

Итак, моя перспектива заключается в том, что Browsify-rails лучше всего перейти от старого JavaScript к CommonJS, а затем перейти от конвейера активов.

Но каждый может свободно использовать его, как они считают нужным. Существует некоторая польза для подключения обновления страницы к сборке активов. Для разработчиков Ruby, используемых для работы с Rails, это простое "это то, как он работает" имеет смысл. Хотя с помощью Procfile не сложно запускать webpack/browsify при просмотре активов и перекомпиляции по мере необходимости. Поэтому я понимаю, что существует множество вариантов использования.

_{cymen прокомментировал 18 декабря 2015 года:}

Я переключил работодателей, и теперь я использую webpack напрямую (что мне нравится - предыдущий инженер сделал этот выбор, и он отлично работает, я думаю, что браузер тоже хорош). Но я работаю над клиентскими веб-приложениями, поэтому наш бэкэнд - это, как правило, API на основе Ruby, работающий под управлением Sinatra (с помощью NodeJS для рендеринга на стороне службы).

Мой предыдущий работодатель некоторое время использовал браузерные рельсы, но я думаю, что они спрыгнули с конвейера активов. Я не уверен (у меня еще не было возможности поговорить об этом подробно с теми, кто еще работает над этим проектом).

Одна из проблем заключалась в том, что время запуска браузера-рельсов занимало больше времени, особенно на MacBooks нижнего уровня (Airs, старше 13 лет). С Browsify-rails 2.x я думаю, что у нас гораздо больше шансов сохранить высокую производительность, если мы можем обойти проблемы с использованием Sprockets напрямую, вместо того, чтобы использовать Tilt в качестве посредника (как это делаем на browserify-rails 1.x), На самом деле кеширование Sprockets должно быть достаточно хорошим, чтобы мы могли избавиться от браузера-инкрементального (который кэширует сборку браузера, чтобы попытаться повысить производительность), но теперь с 2.x у нас есть кеширование в Sprockets и кеширование в браузере - инкрементный, который, вероятно, слишком сложный).

Это был его последний комментарий по этому вопросу (3 месяца назад). Так что обходной путь, который у вас уже есть, - это лучшее решение, доступное в данный момент (пока кто-то не реализует обнаружение ES6 в браузерах-рельсах).