Summary:
The new Packager/Buck integration passes module factory functions as first argument, so that the complete call can be amended at the end safely at a later point in time.
The call expression as a whole is covered perfectly by the created source map. Appending to that code later won’t break mappings.
`__d` now also accepts an additional `dependencyMap` parameter, which so far is only used by the new Packager/Buck integration. It enables module-local dependency IDs, thus eliminating the need to insert `correct` module IDs when building a bundle. Advantages are that source maps are no longer affected, and that builds can be quicker.
Reviewed By: cpojer
Differential Revision: D4124333
fbshipit-source-id: 12eba15d0b9d8c6624280a2ba1e7e4bc654bc83d
Summary: In order to make `Config` and defaults available to our new code, I’ve added flow types and put default values into one shared modile
Reviewed By: cpojer
Differential Revision: D4044600
fbshipit-source-id: 875ed3ade69c5b22bb3c1b177e7bad732834d476
Summary:
Since jest stopped using node-haste a while ago, we are the only client left.
This brings back node-haste back to fbsource to allow us to iterate faster.
Reviewed By: bestander
Differential Revision: D3641341
fbshipit-source-id: a859f8834765723a3515e2cf265581b9dd83997c
Summary:
This changes the jest preprocessor so that files targetet at node.js will be run with the node-specific transform.
It also adapts tests that relied on inline requires.
Benefit: packager tests run faster now.
Reviewed By: cpojer
Differential Revision: D3562007
fbshipit-source-id: e06c86d545926a5c546458025f505dca115e7ea8
Summary:
This intends to make the devx story better after switching to numeric module IDs:
- `require('<verbose-name>)` works again for dev builds
- In dev builds, Systrace will use the verbose names of modules for markers
Reviewed By: bestander
Differential Revision: D3253318
fb-gh-sync-id: 3425d5086ce28634653a6c8c7f5f11afa1614902
fbshipit-source-id: 3425d5086ce28634653a6c8c7f5f11afa1614902
Summary:This brings back "Use numeric identifiers when building a bundle", previously backed out.
This version passes on the correct entry module name to code that decides transform options.
Original Description:
Since the combination of node and haste modules (and modules that can be required as both node and haste module) can lead to situations where it’s impossible to decide an unambiguous module identifier, this diff switches all module ids to integers. Each integer maps to an absolute path to a JS file on disk.
We also had a problem, where haste modules outside and inside node_modules could end up with the same module identifier.
This problem has not manifested yet, because the last definition of a module wins. It becomes a problem when writing file-based unbundle modules to disk: the same file might be written to concurrently, leading to invalid code.
Using indexed modules will also help indexed file unbundles, as we can encode module IDs as integers rather than scanning string IDs.
Reviewed By: martinbigio
Differential Revision: D2855202
fb-gh-sync-id: 9a011bc403690e1522b723e5742bef148a9efb52
shipit-source-id: 9a011bc403690e1522b723e5742bef148a9efb52
Summary:Make packager transform files before extracting their dependencies.
This allows us to extract dependencies added by transforms (and to avoid including them manually).
It also allows for better optimization and to get rid of the “whole program optimization” step:
This diff utilizes the new worker introduced in D2976677 / d94a567 – that means that minified builds inline the following variables:
- `__DEV__` → `false`
- `process.env.NODE_ENV` → `'production'`
- `Platform.OS` / `React.Platform.OS` → `'android'` / `'ios'`
and eliminates branches of conditionals with constant conditions. Dependency extraction happens only after that step, which means that production bundles don’t include any modules that are not used.
Fixes#4185
Reviewed By: martinbigio
Differential Revision: D2977169
fb-gh-sync-id: e6ce8dd29d1b49aec49b309201141f5b2709da1d
shipit-source-id: e6ce8dd29d1b49aec49b309201141f5b2709da1d
Summary: This updates to the latest published node-haste version, and also adapts code and tests to that version. Future upgrades should be easier.
Reviewed By: bestander
Differential Revision: D2963144
fb-gh-sync-id: 9fd2c84fc49643fb85ee5d9674a5e458d43d44ca
shipit-source-id: 9fd2c84fc49643fb85ee5d9674a5e458d43d44ca
Summary: This installs the 2.0 version of node-haste, removes the DependencyResolver and fixes up all the tests.
Reviewed By: davidaurelio
Differential Revision: D2943416
fb-gh-sync-id: aa83d436a33f910d12ed4cc6e2ad8d5742c123a5
shipit-source-id: aa83d436a33f910d12ed4cc6e2ad8d5742c123a5
Summary:
public
Remove the unused feature for async dependencies / bundle layouts. We can bring it back later, if needed.
Reviewed By: cpojer
Differential Revision: D2916543
fb-gh-sync-id: 3a3890f10d7d275a4cb9371a6e9cace601a82b2c
shipit-source-id: 3a3890f10d7d275a4cb9371a6e9cace601a82b2c
Summary:
node-haste shouldn't ever call process.exit and should leave it up to clients to shut down properly. This change just moves it out into the `Resolver` class – I'll leave it up to David and Martin to improve error handling for the rn packager :)
public
Reviewed By: davidaurelio
Differential Revision: D2889908
fb-gh-sync-id: 6f03162c44d89e268891ef71c8db784a6f2e081d
Summary:
public
At the moment, when the user changes a file we end up pulling the dependencies of the entry point to build the bundle. This could take a long time if the bundle is big. To avoid it, lets introduce a new parameter to `getDependencies` to be able to avoid processing the modules recursively and reuse the resolution responseto build the bundle.
Reviewed By: davidaurelio
Differential Revision: D2862850
fb-gh-sync-id: b8ae2b811a8ae9aec5612f9655d1c762671ce730
Summary:
public
Adds the new polyfill to the relevant tests (Resolver/BundlesLayout)
Reviewed By: martinbigio
Differential Revision: D2878697
fb-gh-sync-id: 9681f16dd19a0b337aac63101450c703bf387346
Summary:
public
The reverted change doesn’t play nice with inline requires, let’s revert it for now.
I will bring it back after fixing it or adapting inline requires
Reviewed By: martinbigio
Differential Revision: D2854771
fb-gh-sync-id: 32fdbf8ad51240a9075b26502decb6328eed4b29
Summary:
public
Since the combination of node and haste modules (and modules that can be required as both node and haste module) can lead to situations where it’s impossible to decide an unambiguous module identifier, this diff switches all module ids to integers. Each integer maps to an absolute path to a JS file on disk.
We also had a problem, where haste modules outside and inside node_modules could end up with the same module identifier.
This problem has not manifested yet, because the last definition of a module wins. It becomes a problem when writing file-based unbundle modules to disk: the same file might be written to concurrently, leading to invalid code.
Using indexed modules will also help indexed file unbundles, as we can encode module IDs as integers rather than scanning string IDs.
Reviewed By: martinbigio
Differential Revision: D2842418
fb-gh-sync-id: 97addd28e964ac5f2b5081dcd3f36124d2864df8
Summary:
At the moment we have to disable strict mode for the transform-es2015-modules-commonjs because strict mode leaks to the global scope and breaks the bridge. It was due to the way the polyfills were bundled in the package. To fix it, I wrapped the polyfill modules in an IIFE. Then when strict mode was enabled some polyfills were broken due to strict mode errors so that was fixed too. Also removed the IIFE from the polyfills that included one.
This diff doesn't enable the strict mode transform since some internal facebook modules depend on it not being enabled. When #5214 lands we could make the default babel config shipped with OSS react-native use strict mode modules and facebook could just modify the babel config to disable it if needed.
This will allow removing `"strict": false` from https://github.com/facebook/react-native/blob/master/packager/react-packager/.babelrc#L16Fixes#5316
Closes https://github.com/facebook/react-native/pull/5422
Reviewed By: svcscm
Differential Revision: D2846422
Pulled By: davidaurelio
fb-gh-sync-id: a3e2f8909aa87dabab2b872c61b887e80220fb56
Summary:
This implements #5073. It adds a static method `PixelRatio.pixel()` which returns the smallest drawable line width, primarily for use in styles.
It also updates the example apps to use the new function.
Closes https://github.com/facebook/react-native/pull/5076
Reviewed By: svcscm
Differential Revision: D2799849
Pulled By: nicklockwood
fb-gh-sync-id: b83a77790601fe882affbf65531114e7c5cf4bdf
Summary:
There's quite a bit of code scattered around the packager regarding ignoring the `providesModule` Haste pragma in any file that isn't in `react-native`, `react-tools` or `parse`. There is even a (passing) test case.
However, there's an edge case.
Take, for example, `fbjs`. It has a module inside of it called `ErrorUtils`. `react-relay` requires this file normally, in Common.JS style, by doing `require('fbjs/libs/ErrorUtils')`. But when `react-native` attempts to require `ErrorUtils` using the HasteModule format (in it's JavaScript initialization), it resolves the `fbjs` `ErrorUtils` module, instead of RN's `ErrorUtils`.
This happens, it turns out, because when a module is read (in `Module._read`), it's not caring about whether or not it should pay attention to `providesModule`, and is just assigning the `providesModule` value as the id of the module no matter what. Then when `Module.getName` is called, it will always use that `data.id` that was set, thus creating the wrong dependency tree.
This
Closes https://github.com/facebook/react-native/pull/3625
Reviewed By: svcscm
Differential Revision: D2632317
Pulled By: vjeux
fb-gh-sync-id: efd8066eaf6f18fcf79698beab36cab90bf5cd6d
Summary: Extracts the module system from the list of dependencies and adds it back to the bundling process.
Unbundling and Prepack has their own module systems. jest does as well. This is not normally part of the resolver, nor polyfills.
In fact, I think we'll eventually start treating polyfills as normal modules just like core-js.
The prelude is the weird part right now but I think that we'll eventually move the DEV flag to be module level instead of global and we can just get rid of this prelude.
public
Reviewed By: davidaurelio
Differential Revision: D2693701
fb-gh-sync-id: a59ccda0fa15fcfcda52897e8290805eed1b92b3
Summary: I'm planning to split up `DependencyResolver` into the react-native specific implementation of it and a new, generic resolver that is going to replace `node-haste` for jest and other places where we might need JS dependency resolution.
The plan is to split the two folders up so that:
* `Resolver` is the folder for all the react-native specific resolver code
* `DependencyResolver` will become a standalone library, eventually moving into a package called `node-haste`.
There is still a lot to be figured out. This is just the first diff of likely many. The current goal is to make `DependencyResolver` standalone to be able to create an instance of a resolver and resolve all dependencies for a file. This is when I can start integrating it more seriously with jest.
This diff simply moves a bunch of things around and turns `HasteModuleResolver` into an ES2015 class ( :) ).
bypass-lint
public
Reviewed By: davidaurelio
Differential Revision: D2614151
fb-gh-sync-id: ff4e434c4747d2fb032d34dc19fb85e0b0c553ac
