Summary:
The first time I tried to commit this changeset, it was causing many new packages to be installed, because the dependency would depend on newer versions that what we have installed. So, I had made a diff so upgrade all the babel packages. Unfortunately this caused some problem as the newer versions of Babel are more strict on some syntaxes. Of course, these have to be addressed, but I don't want this changeset to be coupled with Babel upgrades and the issues that arise from it.
So instead, I decided to install the slightly older version of the async-to-generator module. At first I tried with just doing:
yarn add babel-plugin-transform-async-to-generator@6.16.0
But, `yarn` is stubborn: because this module depends on a caret version of `babel-helper-remap-async-to-generator`, it installs the very last version of it, that itself needs more recent versions of other Babel modules. So, instead, I add to install a slightly older version of the dependency manually, then then the plugin:
yarn add babel-helper-remap-async-to-generator@6.16.0
yarn add babel-plugin-transform-async-to-generator@6.16.0
This allows us to have a `yarn.lock` with only a minimal amount of changes, and uncouple this change from any Babel upgrades. Because we only have a few new modules, the `node_modules` folder also stays the same, 133M, and it gives us confidence this will not cause significant startup time regressions.
Reviewed By: cpojer
Differential Revision: D4578733
fbshipit-source-id: deb0f720b895b7196aaf432adec3e56f18663940
Summary:
allow-large-files
By using async/await the code is (1) less nested, (2) more compact and (3) more robust (no exceptions running away, and much less risks of forgetting to call the callback/resolve, or mistakenly calling it twice). I now tend to think we could switch to it for all the callsites that are not in a perf-critical path.
I switched from 'request' to 'node-fetch' because 'request' has an annoying callback with 2 arguments. So it's simpler to use an interface that's (1) already returning a Promise and (2) that is becoming standard.
This changeset was a way for me to start experiment with introducing async/await in packager codebase, and it looks pretty good so far.
Reviewed By: cpojer
Differential Revision: D4559167
fbshipit-source-id: 89a328c5766c2ba890e9d0e67a81a38dac6cfc73
Summary: I figured out that the uncaught rejection that happens on transform error originated from a "fork" along the chain, where we both "then" on a promise, and return that promise. In that case Node.js, legitimately I think, identifies this as an uncaught rejection case. One solution, in this changeset, is to do the side-effects as part of the promise chain instead of "forking". Another option would be to add an explicit error handler to the additional "then", but it seems we don't have to handle that case here.
Reviewed By: davidaurelio
Differential Revision: D4515592
fbshipit-source-id: 17d813cfdbc76685b6273b8d94e97d948fd68674
Summary:
This moves the `src` directory one level up and removes the `react-packager` folder. Personally, I always disliked this indirection. I'm reorganizing some things in RNP, so this seems to make sense.
Not sure if I forgot to update any paths. Can anyone advice if there are more places that need change?
Reviewed By: jeanlauliac
Differential Revision: D4487867
fbshipit-source-id: d63f9c79d6238300df9632d2e6a4e6a4196d5ccb
Summary: We can simplify as there's only one option, and it seems to me we can also make it required, as otherwise the `JSTransformer` is essentially doing nothing. I don't believe we still have use cases where no transform happens at all, even in OSS?
Reviewed By: davidaurelio
Differential Revision: D4481723
fbshipit-source-id: b2e3830b206d56242d298ff3a7b5f4587ecfd29a
Summary: It's not used from any callsite as far as I can see.
Reviewed By: davidaurelio
Differential Revision: D4481708
fbshipit-source-id: 2c503fb7ef20f9370a950c315832f3ace4709739
Summary: it's not used from any callsite as far as I can see.
Reviewed By: davidaurelio
Differential Revision: D4481699
fbshipit-source-id: 4cf63ef7953d6cfc58e7ef4f22ecb99bf51e76a0
Summary: It's not used in any callsite.
Reviewed By: cpojer
Differential Revision: D4481683
fbshipit-source-id: 3fa55693f5f56b4fb6c455ad77d7780f69be81a9
Summary: The idea is to make it easier to interact with tools consuming the packager's output. For example, Nuclide. Do you think that'd work well?
Reviewed By: davidaurelio
Differential Revision: D4482041
fbshipit-source-id: 6c64d7963195a4d786ed8902640f9e9f279f5f83
Jean Lauliac
Christoph Pojer
Jhen
Alexey Kureev
Bhuwan Khattar
cpojer