Summary:
@public
The current output of console.log is extremely bad. If you pass NaN, it shows up as null (super confusing I know -_-), if you pass a cyclical object, it just says that it is cyclic and that's it. It doesn't print up the first few levels which are NOT cyclical and would be really helpful.
It turns out that nodejs console.log pretty printer is really awesome and can be easily extracted as a few hundred lines. This is going to be such a productivity boost that I think it's the right tradeoff to embed it like this
Test Plan:
```
var a = {kikoo: {lol: 1}}
a.kikoo.nice = a;
console.log(a);
> { kikoo: { lol: 1, nice: [Circular] } }
console.log(NaN)
> NaN
```
Summary:
@public
corrected small typo in the 500 response from the packager server
Test Plan: add throw to promise function prior to error handler, run packager, cache a bundle with bundle extension URI, open /debug/packages, see clean 500 error
Summary:
@public
Fixes#773, #1055
The resolver was getting a bit unwieldy because a lot has changed since the initial writing (porting node-haste).
This also splits up a large complex file into the following:
* Makes use of classes: Module, AssetModule, Package, and AssetModule_DEPRECATED (`image!` modules)
* DependencyGraph is lazy for everything that isn't haste modules and packages (need to read ahead of time)
* Lazy makes it fast, easier to reason about, and easier to add new loaders
* Has a centralized filesystem wrapper: fast-fs (ffs)
* ffs is async and lazy for any read operation and sync for directory/file lookup which makes it fast
* we can easily drop in different adapters for ffs to be able to build up the tree: watchman, git ls-files, etc
* use es6 for classes and easier to read promise-based code
Follow up diffs will include:
* Using new types (Module, AssetModule etc) in the rest of the codebase (currently we convert to plain object which is a bit of a hack)
* using watchman to build up the fs
* some caching at the object creation level (we are recreating Modules and Packages many times, we can cache them)
* A plugin system for loaders (e.g. @tadeuzagallo wants to add a native module loader)
Test Plan:
* ./runJestTests.sh react-packager
* ./runJestTests.sh PackagerIntegration
* Export open source and run the e2e test
* reset cache
* ./fbrnios.sh run and click around
Summary:
@public
We cached based on url, which wasn't unique becuase some options would be defaulted. This was obvious when starting the server via fbrnios which tries to warmup the bundle.
And then when the device woke up it will send a request (that is identical in reality) but would miss the cache.
This changes the cache key into a JSON stringification of the options.
Test Plan:
* ./runJestTests.sh
* ./fbrnios.sh run
Summary:
@public
Fixes#1431Fixes#1005
Files with no newlines and a comment at the end of the file would've caused a syntax error in the bundle:
```js
__d('module', function() {
hi();
// wow })
```
This fixes the issue by inserting a new lines before `})`.
Test Plan:
* ./runJestTests.sh
* ./runJestTests.sh PackagerIntegration
* open app to the playground app
* add an error
* observe that the redbox has the correct lines
Summary:
@public
Fixes#773
This fixes `.json` name resolution. And also reads `package.json` when doing a directory module resolution.
The algorithm can be found here: https://nodejs.org/api/modules.html
I'll probably start including the node (or browserify) modules test in later diffs to make sure we're fully compliant.
Test Plan:
* ./runJestTests.sh
* ./runJestTests.sh PackagerIntegration
* open playground and require a json file
* test redbox
Summary:
@public
Fixes issue #1055
For some historical reason we used to strip the extension of the module name before passing it to `resolveDependency` which is completly capable of handling all kinds of names. The fix is one line, but added a few tests for this.
Test Plan:
* ./runJestTests.sh
* ./runJestTests.sh PacakgerIntegration
* Open app and click around
Summary:
@public
The packager's resolver started out imitating node-haste, which meant that we didn't support nested modules. Now this is a problem. Bigger projects are bound to have versions of different versions of the same package at different levels of the dependency tree. This
makes loading dependencies lazy for node_modules and implements the node resolution algorithm. However, it also mantains that some
modules are still "haste" format, which currently defaults to "react-native" and "react-tools".
Finally, this means ~5 seconds speed up on every server start. This should also have a big impact on open source users with projects with big node_modules.
Test Plan:
1- test the app with --reset-cache
2- click around test and production apps
3- update the OSS library
4- create a new project
5- npm install multiple modules
6- create some version conflict in your project
7- make sure we do the "right" thing
8- test file changes to make sure it works
Summary:
@public
Previously, we had to use errors as a property on the result object because there was no way to pass custom props between
the child worker and the parent. This has been fixed in node-worker-farm (D2092153) and now we can use regular errors.
This also adapts the transformer to babel-specific errors. Generic errors, however, should still work and render readable
info.
Additionally, I deprecated, but maintained backwards compatiblity for people in OSS that are using custom transformers.
Test Plan:
1. `./runJestTests.sh`
2. `./runJestTests.sh PackagerIntegration`
3. open the playground app
4. Add a syntax error. Say `1=x` somewhere in the file
5. Reload and see error message 'SyntaxError <filename> description (line:col)'
6. Make sure that the stack trace is clickable and it attempts to open the editor to the location
Summary:
@public
1. Default to first class support of popular image formats
2. Add tests to make sure we support other than png
Test Plan:
1. ./runJestTests.sh
2. Add test.png and test.jpg images in the Playground app dir
3. require both images and render then in the playground app
4. they render
Summary:
@public
Shouldn't confuse the cache from files transformed by different transformers. This takes into account the transformer in the cache hash name.
Test Plan:
* start server with --babel
* generate bundle
* start server with --jstransform
* generate bundle
* compare them and they're different
Summary:
@public
Currently, every time we call into the packager we have to change the ulimit to make sure
we don't hit the EMFILE error (the packager uses as much concurrency as possible).
Using graceful-fs, the fs module -- with monkey patching -- becomes intelligent enough to recover
from EMFILE errors.
Test Plan:
* set `ulimit -n 256*
* start server
* request from your browser: http://localhost:8081/RKJSModules/MainBundle/CatalystBundle.includeRequire.bundle
* it works
Summary:
@public
Fixes [#393](https://github.com/facebook/react-native/issues/393). Currently the transformer assumes line-preserving compilers and defaults to a super-fast source map generation process. However, we need to support compilers that aren't preserving lines.
I had feared this wuold slow down the server but I came about a little known peace of the spec that defines an "indexed source map" just for the purpose of concating files: https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit
Test Plan:
1. runJestTests.sh
2. run server and click around example apps
3. add a custom transporter like babel
4. add a custom file and a debugger statement
5. debug in chrome and make sure it works
redbox still works
Summary:
cc @amasad
An error occurred while trying to display the Red Box since loadSourceMap was not included in the JS
bundle. This is because node-haste was treating its docblock as a multiline directive which doesn't make sense for `@providesModule`.
In loadSourceMap.js's case, the directive's value was parsed as "loadSourceMap -- disabled flow due to mysterious validation errors --".
There are two fixes: add a newline under the `@providesModule` directive, and change the module ID code to look at only the first token of the directive. I opted for the latter so we avoid this class of bugs entirely and AFAIK it's nonsensical to have multiple `@providesModule` values anyway.
Closes https://github.com/facebook/react-native/pull/866
Github Author: James Ide <ide@jameside.com>
Test Plan: Run the packager, trigger an error in an app, see the red box now show up again.
Summary:
@wez Mentioned this in Issue #239 -- right now when watchman takes too long we recommend you run `watchman` from your terminal which actually expects some arguments, so it prints out the following:
```
[pcottle:~/Desktop/react-native:changeErrorMessage]$ watchman
{
"error": "invalid command (expected an array with some elements!)",
"cli_validated": true,
"version": "3.0.0"
}
```
basically this ends up being more confusing since the command we recommend you run errors out, so lets change it to `watchman version` which at least exists cleanly.
I kept the troubleshooting link as https://facebook.github.io/watchman/docs/troubleshooting.html since it sounds like we will update that with the issue people run into in #239
Closes https://github.com/facebook/react-native/pull/825
Github Author: Peter Cottle <pcottle@fb.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Christopher Chedeau
Forbes Lindesay
Bill Fisher
Amjad Masad
Tadeu Zagallo
Spencer Ahrens
Eric Vicenti
Nick Lockwood
Dmitry Soshnikov
Alex Kotliarskyi
Tim Yung
Kevin Gozali
Philipp von Weitershausen
James Ide
Peter Cottle