Summary:Needs to be published to npm and version be updated in RN
Closes https://github.com/facebook/react-native/pull/7208
Differential Revision: D3218870
Pulled By: davidaurelio
fb-gh-sync-id: 1caac6eb79be16f2e3ed230f413835341c7291dc
fbshipit-source-id: 1caac6eb79be16f2e3ed230f413835341c7291dc
Summary:Stateless function components (at least those using arrow functions) are not assigned names when this transform is omitted.
Rebased against master and kept the original author from #6717
cc martinbigio bestander
Closes https://github.com/facebook/react-native/pull/6794
Differential Revision: D3133791
Pulled By: mkonicek
fb-gh-sync-id: bb7790ad17d1520da5ab95580548d29d0c0f397d
fbshipit-source-id: bb7790ad17d1520da5ab95580548d29d0c0f397d
Summary:Tested HMR on Windows and found 2 small issues related to paths that made it not work. Now it works nicely :)
**Test plan (required)**
Tested HMR in UIExplorer on Windows.
Closes https://github.com/facebook/react-native/pull/6678
Differential Revision: D3138379
fb-gh-sync-id: f27cd2fa21f95954685c8c6916d820f41bc187be
fbshipit-source-id: f27cd2fa21f95954685c8c6916d820f41bc187be
Summary:Since #5422 react-native works with strict mode modules but the transform was not updated since Facebook has some non strict mode compatible internal modules. Now that #5214 has landed and it is easy to change the babel config I think we should enable it by default to make es2015 modules spec compliant.
Someone at Facebook will have to make the internal changes necessary to disable strict mode modules for their projects that use non strict mode compatible modules by including a .babelrc file with
``` json
{
"presets": [
"react-native"
],
"plugins": [
["transform-es2015-modules-commonjs", { "strict": false, "allowTopLevelThis": true }]
]
}
```
before merging this.
We might also want to mention this in the breaking change section for the next release.
Closes https://github.com/facebook/react-native/pull/5796
Differential Revision: D3075802
fb-gh-sync-id: e807b67401107e1e944db38453e254025ce0a6c7
shipit-source-id: e807b67401107e1e944db38453e254025ce0a6c7
Summary:This imports `react-transform-hmr/lib/index.js` with a relative path from every module, to make sure we don’t rely on the current (broken) behaviour.
It works now, because:
- the dependency is added by a transform
- we extract dependencies before transforming
- we include `react-transform-hmr/lib/index.js` manually
- packager incorrectly names modules by the name of their package (i.e. packages with multiple versions overwrite each other)
This blocks transforming before extracting dependencies, switching to numeric module IDs, and unbundling/random access bundles.
Reviewed By: bestander
Differential Revision: D2994024
fb-gh-sync-id: 23c56397b768775ff56e3d6924f50a9e39e8ce8c
shipit-source-id: 23c56397b768775ff56e3d6924f50a9e39e8ce8c
Summary:
Turns out, even after discussion that was had in https://github.com/facebook/react-native/pull/5294#issuecomment-174397103, we really do need this transform.
I've just included it in the preset...let me know if you all would rather publish to npm.
The actual reason why this is necessary is because in the latest sync from FB, fbjs was updated to use the `Symbol.iterator` express in it's isEmpty function: 064a484e18
We use this in RN in the ListView...and this change (once #5084 is merged) will cause ListView to break on older JSC context's.
This resolves that, and is probably something we should have had all along.
Closes https://github.com/facebook/react-native/pull/5824
Reviewed By: svcscm
Differential Revision: D2913315
Pulled By: vjeux
fb-gh-sync-id: abaf484a9431b3111e8118d01db8d2c0d2dd73ca
shipit-source-id: abaf484a9431b3111e8118d01db8d2c0d2dd73ca
Summary:
Rather than specifying Babel plugins in the `.babelrc` packaged with react-native, leverage a Babel preset to define the plugins (https://github.com/exponentjs/babel-preset-react-native).
This allows for a much better user experience for those who want (or need) to override options in their project's `.babelrc`.
Prior to this PR, if a user wanted to use a custom babel-plugin (or a custom set of babel plugins), they'd have either 1) manually override the `.babelrc` in the react-packager directory (or fork RN), or 2) specify a custom transformer to use when running the packager that loaded their own `.babelrc`. Note - the custom transformer was necessary because without it, RN's `.babelrc` options would supersede the options defined in the project's `.babelrc`...potentially causing issues with plugin ordering.
This PR makes the transformer check for the existence of a project-level `.babelrc`, and if it it's there, it _doesn't_ use the react-native `.babelrc`. This prevents any oddities with Babel plug
Closes https://github.com/facebook/react-native/pull/5214
Reviewed By: davidaurelio
Differential Revision: D2881814
Pulled By: martinbigio
fb-gh-sync-id: 4168144b7a365fae62bbeed094d8a03a48b4798c
Konstantin Raev
Daniel Friesen
Janic Duplessis
Martin Bigio
David Aurelio
Adam Miskiewicz