macos

нет, особенно если используешь Expo

у меня были проблемы, я их решил

да, вполне

спасибо, прям вдохновил меня, использую для знакомства с rn

что тоже не идеал далеко, но конкурентов нет 🙂

А на какой ОС вы работаете?

macOS, android разработку сейчас на linux переношу (т.к. Apple в high sierra что-то такое сделала с WindowServer (это как-то с их миграцией на metal2 связано), что теперь некоторые фичи OpenGL, используемые в Android Emulator или Android Studio роняют мне ось)

Ясно, понятно. Видимо поэтому у тебя не возникало проблем с RN 0.56 https://github.com/facebook/metro/issues/181

Этой проблемы не возникало. Там в master уже что-то коммитили на эту тему... сейчас поищу

Да и я только что проверял тоже, проблема воспроизводится

Коллеги, доброе утро. Обновлялся ли кто-то до RN 0.55.4 с установленным storybook и addon'ом к нему @dump247/storybook-state? Я обновлялся с версии 0.53.3. Возникает проблема, когда metro-bundler пытается собрать для меня js бандл. Выдается ошибка следующего типа: error: bundling failed: ReferenceError: Unknown plugin "transform-react-remove-prop-types" specified in "C:\\GIT\\rn\\node_modules\\@dump247\\storybook-state\\.babelrc" at 0, attempted to resolve relative to "C:\\GIT\\rn\\node_modules\\@dump247\\storybook-state" Такое чувство, что бандлер пытается собрать этот addon из исходников на основании его .babelrc, где как раз указано, что нужен плагин transform-react-remove-prop-types, хотя эта библиотека предоставляет уже транспиленную версию. @dump247/storybook-state/package.json { ... "main": "dist/index.js" ... } Может кто-то с похожей проблемой сталкивался?

Я просто решил свой небольшой проект перенести с RN 0.53.3 на последнюю версию, и уже второй день мудохаюсь. Плюнул с последней, решил хотя бы на предыдующую 0.55, т.к. там не такие страшные breaking changes.. и все равно какие-то проблемы по типу той, что я писал выше.

Я в какой-то момент очень надеялся, что haul будут активно развивать, тогда от всей этой прослойки с нестабильным metro и глупейшей haste можно было бы отказаться... но они затормозили в развитии... но хотя бы haste они начали выпиливать...

почему haste глупейший?) то что непривычно и сходу совсем непонятно, это да)

А в двух словах, чем занимается haste?

почему haste глупейший?) то что непривычно и сходу совсем непонятно, это да)

Может немного эмоционально выразился. Сейчас объясню, постараюсь кратко. Когда я учил javascript, то одной из вещей, восхитившей меня, была система модулей, в которой один и тот же пакет может существовать в разных версиях. Из тех языков, что я тогда знал, никто этого не умел и это приводило к страшному гемморою с конфликтующими зависимостями, когда тебе нужен модуль B, который зависит от A версии 1 и модуль C, который тоже зависит от A, только версии 2. И всё... достучаться до автора модуля B невозможно... при большом кол-ве модулей это становится гигантской проблемой. Вызвает её то, что в большинстве других языков пространство имен модулей глобально, т.е. в Perl, если у тебя есть модуль DBIx::Class, то это всё, ничего больше он в это имя не положит, если ты там что-то поправишь, то это увидят все остальные модули и т.п. В компилируемых языках ещё хуже... там для совместимости со стандартным редактором связей все именованные экспортируемые сущности глобальны. Т.е. нельзя иметь в C++ два класса с одинаковым именем. Соотвественно две версии одной и той же библиотеки. И так далее... В javascript же, модуль импортируется локально... и это позволяет избежать всех подобных проблем (да, добавляет другую, типа модуль A может производить объекты, которые если скормить другой версии того же модуля, вызовут ошибки) это добавляет гибкости, оставляя возможность редкие проблемы решать людям. И вот я вижу, что в погоне за краткостью написания импортов, кое-кто берет и убивает эту гибкость одним легким движением руки. Не глупо ли? Заодно можно добавить сюда медленный ресолвинг (это конкретно haste), т.к. теперь надо не только по fs погулять, но ещё и каждый файл прочитать чтоб эти макрекры найти. Это вызывает необходимость иметь сложную систему кеша, которая ломается и всё равно работает не очень быстро, зато жрет память. Достаточно? )))

сейчас такая "мода" есть, что создают папку с модулем, а внутри index.js, так вот потом этих непонятных файлов index становятся куча) с haste ты хоть гарантировано find-ом найдешь быстро файл) но это конечно все равно ооочень непривычно видеть) понятно что как всегда трейд оф, видимо фб хорошо так жилось, поди пойми что им нравится 😄

@savelichalex @gblack9 может вы знаете. Я вот так и не очень понял, это теперь нормально, что metro пытается транспилить третьи библиотеки из node_modules на основе .babelrc у каждой библиотеки?

Не знаю... тренд был вообще не транспилить их... и чтоб включить транспиляцию для них, надо было отдельно регексп писать в rn-cli.config.js (или package.json)

Т.е. вообще-то для меня - это не нормально, ведь авторы библиотек транспилят все за нас при публикации в npm

ща... ищу... какая у вас версия metro?

Не знаю... тренд был вообще не транспилить их... и чтоб включить транспиляцию для них, надо было отдельно регексп писать в rn-cli.config.js (или package.json)

плюсую) тоже помню в каком то из релизов про это говорили)