Summary:
`react-native start` already ensures that the `--transformer` path is understood to be relative to CWD, not to the module that ends up importing that file. `react-native bundle` and `react-native dependencies` didn't up until this point.
**Test plan:** Ensured that `react-native bundle ... --transformer ./relative/path` works with this patch applied.
Closes https://github.com/facebook/react-native/pull/7857
Differential Revision: D3393777
fbshipit-source-id: 303a226fae9c8087c3dd3b2e8d004462ca66665e
Summary:
This separates the babel config of the local-cli and the packager from the one used by the transforms of the packager since it doesn't run in the same environment and the local-cli/packager doesn't require react specific transforms and runs in node 4 so we can also avoid some es2015 transforms that node already supports.
I had to move the code in cli.js so it can still run in node 0.12 that doesn't support `const` since it is no longer transformed.
**Test plan**
Run the local-cli on node 0.12 and there should be a message saying that it requires at least node 4.
Run the local-cli on node 4 and 5 and everything should work the same as before.
I was also hoping for some perf gains but there was nothing noticeable. I did benchmark the babel-register call and it stayed pretty much the same. As for runtime performance it can help if there are optimisations for es2015 features in node.
Closes https://github.com/facebook/react-native/pull/6155
Reviewed By: bestander
Differential Revision: D3301008
Pulled By: davidaurelio
fbshipit-source-id: 504180d158a1e50bc03e28fb0d1e53d0731ce32f
Summary:
This separates the babel config of the local-cli and the packager from the one used by the transforms of the packager since it doesn't run in the same environment and the local-cli/packager doesn't require react specific transforms and runs in node 4 so we can also avoid some es2015 transforms that node already supports.
I had to move the code in cli.js so it can still run in node 0.12 that doesn't support `const` since it is no longer transformed.
**Test plan**
Run the local-cli on node 0.12 and there should be a message saying that it requires at least node 4.
Run the local-cli on node 4 and 5 and everything should work the same as before.
I was also hoping for some perf gains but there was nothing noticeable. I did benchmark the babel-register call and it stayed pretty much the same. As for runtime performance it can help if there are optimisations for es2015 features in node.
Closes https://github.com/facebook/react-native/pull/6155
Differential Revision: D3242754
Pulled By: eczarny
fb-gh-sync-id: 6cd349e284b7d92a1b2cc8b5c0e26adbfb0d9a2f
fbshipit-source-id: 6cd349e284b7d92a1b2cc8b5c0e26adbfb0d9a2f
Summary:
This separates the babel config of the local-cli and the packager from the one used by the transforms of the packager since it doesn't run in the same environment and the local-cli/packager doesn't require react specific transforms and runs in node 4 so we can also avoid some es2015 transforms that node already supports.
I had to move the code in cli.js so it can still run in node 0.12 that doesn't support `const` since it is no longer transformed.
**Test plan**
Run the local-cli on node 0.12 and there should be a message saying that it requires at least node 4.
Run the local-cli on node 4 and 5 and everything should work the same as before.
I was also hoping for some perf gains but there was nothing noticeable. I did benchmark the babel-register call and it stayed pretty much the same. As for runtime performance it can help if there are optimisations for es2015 features in node.
Closes https://github.com/facebook/react-native/pull/6155
Differential Revision: D3242754
Pulled By: davidaurelio
fb-gh-sync-id: 02880c841c10562d5f107e1c975d668e55cc619f
fbshipit-source-id: 02880c841c10562d5f107e1c975d668e55cc619f
Summary:
Now packager only listen to "::", which is IPv6 "Any address".
It failed to run in IPv4 Environment.
defaults to undefined or empty string will fix this.
And I think it's necessary to let user define host by cli argument.
It's also for security reason. When working on a public network, it's much safer to listen with localhost instead of ::, which may let everyone in same network be able to get your code from debugger-ui.
recommit for #1918, fixes#2441
Closes https://github.com/facebook/react-native/pull/5377
Reviewed By: svcscm
Differential Revision: D2842594
Pulled By: martinbigio
fb-gh-sync-id: 575944c5469dac80e99136a7903ea99f5339dba1
Summary:
public
We want to support Hot Loading on the packager itself instead of on the transformer. This will allow us to enable it on OSS (and for any scripting language, yay!).
For now to enable Hot Loading the packager's internals transforms need to be manually enabled (start packager with `--enable-internal-transforms`). I think the internal pipeline should always be enabled as it doesn't affect performance if there're no transforms and the user can disable Hot Loading through the setting on the app though. I'll tweak this on a follow up commit.
Reviewed By: vjeux
Differential Revision: D2801343
fb-gh-sync-id: 563984d77b10c3925fda6fd5616b814cdbea2c66
Summary:
public
This diff introduces an internal transforms pipeline that integrates with the external one. This has been a feature we've been looking to implement for a long time to use babel instead of `replace` with regexps on many parts of the packager.
Also, to split the bundle we'll need to run one transform. Internally for Facebook we can run the system-import transform altogether withe the other ones. For OSS we offer `transformer.js` which people can use out of the box if they're writing ES6 code. For those people, `transformer.js` will also run the internal transforms`. However they might want to tune the transforms, or even write the code on another language that compiles to Javascript and use a complete different transformer. On those cases we'll need to run the external transforms first and pipe the output through the internal transforms. Note that the order it's important as the internal transforms assume the code is written in JS, though the original code could be on other scripting languages (CoffeeScript, TypeScript, etc).
Reviewed By: davidaurelio
Differential Revision: D2725109
fb-gh-sync-id: d764e209c78743419c4cb97068495c771372ab90
Summary: Currently on error I have following output:
```
ERROR Packager can't listen on port 8081
Most likely another process is already using this port
Run the following command to find out which process:
lsof -n -i4TCP:8081
You can either shut down the other process:
kill -9 <PID>
or run packager on different port.
See http://facebook.github.io/react-native/docs/troubleshooting.html
for common problems and solutions.
/Users/nucleartux/Work/projects/react-native/local-cli/server/server.js:90
if (error.code === 'EADDRINUSE') {
^
TypeError: Cannot read property 'code' of undefined
at process.<anonymous> (/Users/nucleartux/Work/projects/react-native/local-cli/server/server.js:104:14)
at emitOne (events.js:77:13)
at process.emit (events.js:169:7)
at process._fatalException (node.js:211:26)
```
Closes https://github.com/facebook/react-native/pull/3765
Reviewed By: svcscm
Differential Revision: D2595537
Pulled By: martinbigio
fb-gh-sync-id: e11ec2e6e8794bf5fe7570e27cd327777d8b300c
Summary: public
This is not only to put the files on a place where it makes more sense but also to allow to use ES6 features on them as `/packager` is not whitelisted on `babel`.
Reviewed By: mkonicek
Differential Revision: D2577267
fb-gh-sync-id: b69a17c0aad349a3eda987e33d1778d97a8e1549
Summary: public
We cannot remove `local-cli` because is referenced by the global cli explicitly. If we do so, people would have to upgrate this global thin cli which will cause some pain. So, lets move `private-cli` commands into `local-cli` instead.
Reviewed By: frantic
Differential Revision: D2571983
fb-gh-sync-id: 712c29430203660fb6f0d5f23813cb2a7156ee48
Philipp von Weitershausen
Janic Duplessis
DengYun
Martín Bigio
Christopher Dro
James Ide
Adrov Igor