React-native: Packager Wishlist

Created on 26 Oct 2016  Â·  8Comments  Â·  Source: facebook/react-native

I'd like to collect a list of things from the open source community about what could be improved about react-native's packager. Please feel free to share any issues, feature requests or outrageous ideas that you might have. Thank you!

Locked

Most helpful comment

Reliability and lack of surprises:

  • Correct caching: currently it's possible to get into states where the cache is invalid. I'm not sure what the precise repro conditions are but it's hard to get this right and I believe there are holes in the cache invalidation policy, which needs to cover changing rn-cli.config.js, --transformer, babelrc, upgrading Babel in node_modules, and so on. The goal here is to increase trust in the packager and not need to clear its cache, improving warm performance.
  • Symlink support: as covered in a comment above. Again, I'd want this to be trustworthy and not break if the packager is running while symlinks are added or removed.
  • Handle Watchman errors: For example, sometimes watchman warns that it's recrawling a directory, it'd be nice if the packager could figure out the right thing and fix the situation for me.

Features:

  • Bundle splitting: The idea is to implement something like asynchronous import() as well as FB's style of require(). FB's require() on www is pretty interesting because it's synchronous yet allows for bundle splitting.
  • Scoping Haste: The idea is to let people use Haste directives within packages but not between packages. That way a lot of Haste-related bugs across packages would go away but packages and apps could use Haste themselves without globally affecting others.
  • Output Variants: Basic idea is to be able to generate different bundles for different target platforms like iOS 10 (modern JSC) vs iOS 8/9. This is related to but different than supporting different input sources (.ios.js, .android.js).
  • More programmatic access: More programmatic access to everything from stats about the bundles, asset files, the packager's output, and so on would be slightly useful.
  • More precise choosing what to transpile: Support for the "sources.react-native" field in package.json to allow authors to publish rich, ES2016 code to npm and let people benefit from it, while skipping transpilation of ES5-only packages. Proposal here: https://gist.github.com/ide/e7b9181984933ebb0755c7367a32e7e8

Flexibility:

  • More flexibility in the packager means that the core packager needs fewer features.
  • Custom file loaders: This is to let people customize how to load files or files of a package. Use cases: perhaps instead of the main field in package.json they want to load another field (ex: some ideas I showed you @cpojer before). Also loading files from a caching service instead of disk to avoid disk I/O. Additionally, this would let people configure how to load non-JS files too.
  • Custom transformers: The idea is to let people inject their own transformers very easily. Async functions would let people read/write to cache servers as well as Node worker pools for Babel transformations (or whatever transformation they want to do). Koa's middleware is one of the sanest ways to compose plugins that I've seen, I think it'd be good to pattern off of it if you go in this direction. I really love this general idea because if the transformers have enough context, so many features can be implemented in "user space" without needing to add them to the core packager.
  • Custom bundle splitters: The policies for how to batch files together are really diverse. Ship a simple implementation with RN (bundle everything together in one file) but let people write their own policies if they want something more advanced.
  • Custom file bundlers: Likewise, the way to join files together into a bundle is something people may want to customize differently.

All 8 comments

FWIW, on Product Pains the top packager request is symlinks. @Kureev is working on that but I think there are still some rough edges. https://productpains.com/post/react-native/symlink-support-for-packager

Also FWIW, the second most popular packager request on Product Pains is the ability to shim one module for another like webpack aliases. https://productpains.com/post/react-native/packager-support-resolvealias-ala-webpack (And then the third is a dupe of #1 so I will stop spamming product pains links ;-) )

Reliability and lack of surprises:

  • Correct caching: currently it's possible to get into states where the cache is invalid. I'm not sure what the precise repro conditions are but it's hard to get this right and I believe there are holes in the cache invalidation policy, which needs to cover changing rn-cli.config.js, --transformer, babelrc, upgrading Babel in node_modules, and so on. The goal here is to increase trust in the packager and not need to clear its cache, improving warm performance.
  • Symlink support: as covered in a comment above. Again, I'd want this to be trustworthy and not break if the packager is running while symlinks are added or removed.
  • Handle Watchman errors: For example, sometimes watchman warns that it's recrawling a directory, it'd be nice if the packager could figure out the right thing and fix the situation for me.

Features:

  • Bundle splitting: The idea is to implement something like asynchronous import() as well as FB's style of require(). FB's require() on www is pretty interesting because it's synchronous yet allows for bundle splitting.
  • Scoping Haste: The idea is to let people use Haste directives within packages but not between packages. That way a lot of Haste-related bugs across packages would go away but packages and apps could use Haste themselves without globally affecting others.
  • Output Variants: Basic idea is to be able to generate different bundles for different target platforms like iOS 10 (modern JSC) vs iOS 8/9. This is related to but different than supporting different input sources (.ios.js, .android.js).
  • More programmatic access: More programmatic access to everything from stats about the bundles, asset files, the packager's output, and so on would be slightly useful.
  • More precise choosing what to transpile: Support for the "sources.react-native" field in package.json to allow authors to publish rich, ES2016 code to npm and let people benefit from it, while skipping transpilation of ES5-only packages. Proposal here: https://gist.github.com/ide/e7b9181984933ebb0755c7367a32e7e8

Flexibility:

  • More flexibility in the packager means that the core packager needs fewer features.
  • Custom file loaders: This is to let people customize how to load files or files of a package. Use cases: perhaps instead of the main field in package.json they want to load another field (ex: some ideas I showed you @cpojer before). Also loading files from a caching service instead of disk to avoid disk I/O. Additionally, this would let people configure how to load non-JS files too.
  • Custom transformers: The idea is to let people inject their own transformers very easily. Async functions would let people read/write to cache servers as well as Node worker pools for Babel transformations (or whatever transformation they want to do). Koa's middleware is one of the sanest ways to compose plugins that I've seen, I think it'd be good to pattern off of it if you go in this direction. I really love this general idea because if the transformers have enough context, so many features can be implemented in "user space" without needing to add them to the core packager.
  • Custom bundle splitters: The policies for how to batch files together are really diverse. Ship a simple implementation with RN (bundle everything together in one file) but let people write their own policies if they want something more advanced.
  • Custom file bundlers: Likewise, the way to join files together into a bundle is something people may want to customize differently.

Every time I add an image to my assets/ folder with hot reloading enabled, I get this unexpected character error, which won't go away until I restart the packager or disable hot reloading. No clue what causes this but would love if it were fixed!

screenshot

I hope this is relevant. Maybe it's more of a CLI thing. Unsure if that's the same as packager. But I think it would be great to create a quick command to clean the cache. That is of course unless you can get cache working correctly as ide suggested above, making this moot.

There are a lot of other handy commands that might benefit from shortcut access...
https://medium.com/komenco/useful-react-native-npm-scripts-6c07b04c3ac3#.ij6d2f1el

That should be --reset-cache.

Closing because the issue itself is non-actionable but we are taking all the points raised here into consideration. Thanks for participating and feel free to bring up more issues.

Adding support for custom module directories is something that would be very nice to have. Consider this case:

├───common
│       Foo.js -> requires React
│
└───web
    │   Bar.js -> requires Foo.js
    │
    └───node_modules
        └───react

When running this in the packager Foo.js will not be able to resolve react in web/node_modules/react.

My current solution to this is to copy common/ into the web directory.

also to be able to have multiple module directories like webpack. so that we can do import Foo from 'common/Foo'.
Current workaround there is to add a package.json in the common folder with "name": "common"

Was this page helpful?
0 / 5 - 0 ratings