Summary: @public
We've been forgiving unresolved modules errors in the past but we've realized that doing so makes the codebase a bit unstable as people don't make sure to fix these errors. From now on we'll early fail and stop the packager when any module cannot be resolved (including assets)
Reviewed By: @amasad
Differential Revision: D2518076
fb-gh-sync-id: e170d95b905cc29afbe46e24b65425ddd887f77c
Summary: @public
The legacy 'isStatic' property for image sources is no longer used anywhere in our codebase, but was still being generated by the packager and referenced in the JS in various places.
This diff removes all the remaining references.
Reviewed By: @frantic
Differential Revision: D2531263
fb-gh-sync-id: 0bba0bb8473b1baa908ef7507cbf6d83efb0d9ee
Summary: @public We're moving all the operation from `local-cli` to the `private-cli` and improving the code in the process. On this diff we introduce the `server` command which will be use to start the packager server. On follow up diffs we'll make changes to start using it from `local-cli`.
Reviewed By: @vjeux
Differential Revision: D2531443
fb-gh-sync-id: 5f7f12a250895265d83d1b076f6bbddb5cbdc257
Summary: When you try to install these with old Node you'll now get a message from npm telling you that your version of Node is old. This makes it more obvious what's going on and hopefully reduces the number of issues we get due to people using an old version of Node.
Closes https://github.com/facebook/react-native/pull/3296
Reviewed By: @svcscm
Differential Revision: D2526500
Pulled By: @vjeux
fb-gh-sync-id: 036e10a8d1819ea082e419cd328a458202f0e071
Summary: @public
When doing node <script> some es6 features like const seem to work. But when we extracted some of them into other files and require them through babels require infra it started failing because the paths where those files are located where not on the `only` whitelist.
Reviewed By: @vjeux
Differential Revision: D2525557
fb-gh-sync-id: 79752c4f9b8ff2d20f73cfe27d6a2f3706959d95
Summary: @public
This was a hard one, bare with me on the full story of what happened.
We recently started writting additional JS scripts in ES6 for the cli. These code needs to be transformed by babel before we execute it as we don't run node with `--harmony`. To do so we removed the `only` attribute on the `babel-register`. Turns out this broke the packager on oss as if no `only` not `ignore` parameter is specified babel will ignore `node_modules`. Since on oss when a project is created `react-native-github` is located inside of `node_modules` we started getting syntax errors.
The fix is to include separately all the different paths we need to make sure babel transforms each of them. We cannot simply have a single `babel-core/register` as we need to include paths that belong both to oss and internal only. So, we need to have multiple `register` invocations. Since babel does not accumulate the `only` you send on every invocation we need to build a small wrapper to do so.
Reviewed By: @frantic
Differential Revision: D2522426
fb-gh-sync-id: 379a7bb169c7d5cb3002268742de269238bba766
Summary: @public
The source maps generated by uglify are already stringified, and therefore were
being stringified twice.
Reviewed By: @martinbigio
Differential Revision: D2498242
Summary: @public
Dead-lock trying to read package.json because it's both a "module" and a "package". in `Module.getName` it uses the cache key "name" and tries to call `Package.getName` which uses the same cache key and we end up returning the same promise that we're trying to resolve resulting in a dead-lock.
This changes the cache keys for the packages that adds a prefix "package-".
Reviewed By: @vjeux
Differential Revision: D2506979
Summary: Users should use Node 4.0 instead of io.js. This isn't a hard requirement since io.js still works but it's simpler if everyone is on the latest version.
Closes https://github.com/facebook/react-native/pull/2547
Reviewed By: @svcscm
Differential Revision: D2506388
Pulled By: @vjeux
Summary: @public
Update packager entry and profiler pre-built dylib +
Update makefile to make it easier to use different versions of Xcode
and shortcircuit when using the wrong version.
Reviewed By: @jspahrsummers
Differential Revision: D2498157
Summary: *This is a PR to fix#1939 (DependencyResolver fails to handle ES6 modules import statements with new lines)*
**This PR includes:**
- A fix to the problematic regular expression
- Updated tests that support the new line style.
**Summary:**
We found out that while the packager does its module wrapping thing for lines like this:
```js
import theDefault, { named1, named2 } from 'src/mylib';
```
It fails to do the same for multi line imports:
```js
import theDefault, {
named1,
named2
} from 'src/mylib';
```
We've tracked done the issue to a [faulty regular expression in replacePatterns.js](https://github.com/facebook/react-native/blob/master/packager/react-packager/src/DependencyResolver/replacePatterns.js#L12)
You can see various import statements with the problematic regular expression [here](http://regexr.com/3bc8m)
We've figure out a better regular expression (you can play around with it [here](http://regexr.com/3bd3s))Closes https://github.com/facebook/react-native/pull/1940
Reviewed By: @svcscm
Differential Revision: D2498519
Pulled By: @vjeux
Summary: This is an updated copy of #1993, which was approved by @vjeux but hasn't been rebased. It whitelists the es6 module syntax and updates the JS Environment docs to match. cc @ide @hkjorgensenCloses https://github.com/facebook/react-native/pull/3175
Reviewed By: @svcscm
Differential Revision: D2498360
Pulled By: @vjeux
Summary: @public
This moves us from warnings on name collisions to errors. If the error happens in initialization it will fatal out.
However, if the error happens while working (after initialization) then I did my best to make it recoverable. The rational behind this is that if you're working and you're changing names, you may introduce a duplication while moving things around. It will suck if you have to restart the server every time you do that.
Reviewed By: @frantic
Differential Revision: D2493098
Summary: @public
Since we added packager-managed assets -- internally we still think of asset dependency as a single "module". In reality there are multiple files that represent this module. This becomes important with the `getDependencies` API which is used by Buck to inform it on what to rebuild. Since `getDependencies` deals with modules, and is more of an internal API, I've introduced a new one and would go on to deprecate this.
Reviewed By: @frantic
Differential Revision: D2487207
Summary: @public
Have a top-level debug namespace: `ReactNativePackager`
And add a couple of debugs in the transformer. This is ground work for adding a verbose option.
Reviewed By: @DmitrySoshnikov
Differential Revision: D2489960
Summary: In javascriptcore(ios9), this code will run as expected(output 0 1):
```js
for(let i=0; i<2; i++) {
const data = i;
console.log(data);
}
```
But when debug in chrome, the above code will fail without `use strict` prologue (if you add prologue, rn will fail with red screen `Const declarations are not supported in strict mode`): https://code.google.com/p/v8/issues/detail?id=4432.
So it's better to transpile contant by default.
Closes https://github.com/facebook/react-native/pull/2955
Reviewed By: @svcscm
Differential Revision: D2483398
Pulled By: @vjeux
Summary: @public
Fix the haste resolution algorithm. Changed the map data structure from a list of modules, to a list of modules grouped by platform.
This considerably simplifies the "getModule" method and makes it easy to properly warn about colliding module names.
This also fixes a bug where we used to include `.web` files when we shouldn't (see task).
Reviewed By: @vjeux
Differential Revision: D2482969
Summary: @public
@amasad added a warning when there are two @providesModule with the same name. This removes all those warnings by blacklisting the internal version of those files. Once we get of the big react-tools/ hack, we'll be able to remove all those :)
Reviewed By: @amasad
Differential Revision: D2482521
Summary: @public
The issue of colliding haste modules have came up many times and have wasted countless engineering hours. This will start warning about it and will also start selecting modules at random so that people don't depend on undefined behavior.
Additionally, this surfaced an issue where with assets we may fatally throw if the directory doesn't exist. This is fixed by checking the existence of the directory before trying to match files in it.
Reviewed By: @jingc
Differential Revision: D2478480
Summary: The `react.displayName` transform was added in 93b9329b75.
That diff missed to update the `.babelrc` where the comment says it should stay
in sync (I'm not sure where it's used though). I added a comment in the other
direction so this can be prevented in the future.
I also updated the `cacheVersion` so we actually transform the code again to add
the missing displayName properties to unchanged components.
Closes https://github.com/facebook/react-native/pull/2905
Reviewed By: @vjeux
Differential Revision: D2473447
Pulled By: @kassens
Summary: To make the chrome debugger environment consisten with the JSC executer environment,
where there is no `window.document`, make the chrome debugger run the javascript inside a web worker.
This fixes#1473
Closes https://github.com/facebook/react-native/pull/1632
Reviewed By: @martinbigio
Differential Revision: D2471710
Pulled By: @vjeux
Summary: Ex. When `console.log` or similar is called, this will call
the original method, which can be quite useful.
For example, under iOS, this will log to the Safari console debugger,
which has an expandable UI for inspecting objects, etc., and is also
just useful if you are using that as a REPL.
I don't believe this incurs a meaningful performance penalty unless
the console is open, but it would be easy to stick behind a flag
if that is a problem.
Closes https://github.com/facebook/react-native/pull/2486
Reviewed By: @svcscm
Differential Revision: D2472470
Pulled By: @vjeux
Summary: @public
We swallow errors like it's nobody's business :(
Having an error handler that `reject`s after the promise has been resolved is a no-op. In node, if there is no `error` event handler then the error would throw.
So after we start listening and we want to resolve the promise, we remove the error listener so that we make sure errors actually throw.
Finally, I made the `uncaughtError` handler log `error.stack` so we can get an idea of what's going on.
Reviewed By: @martinbigio
Differential Revision: D2468472
Martín Bigio
Nick Lockwood
James Ide
Christopher Chedeau
Tadeu Zagallo
Amjad Masad
shlomiatar
Martin Konicek
Kyle Corbitt
Pieter De Baets
yiminghe
Justin Spahr-Summers
Jan Kassens
oveddan
Charlie Cheever
Thomas Aylott