New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] Moving react-native-packager into a new repository. #13976

Closed
cpojer opened this Issue May 15, 2017 · 11 comments

Comments

Projects
None yet
9 participants
@cpojer
Contributor

cpojer commented May 15, 2017

Hey everyone!

The JavaScript Tools team at Facebook, especially @davidaurelio and @jeanlauliac, have made big improvements to react-native-packager's performance and reliability this year so far. As more and more people write JavaScript for mobile applications, it is essential for a bundler to be fast, reliable and scalable.

Here are some of the highlights from this half so far:

  • 10x faster source map generation. Read Fast Source Map Generation for React Native.
  • Rewrote symbolication from a 10s blocking call to a ~2s async call (b6ca952).
  • When adding/removing dependencies, the reload time was reduced from 7 seconds to 4 seconds on large repositories at Facebook.
  • Many performance minded improvements (still ways to go!) to improve startup performance. Internally at Facebook, we built a global transform cache with a server that stores all transformed files. This has a public interface, however it requires a separate server implementation in open source – we are happy to give advice if anyone wants to build an open source server component to speed up initial load time for large apps.

Next week we are planning to split react-native-packager off of React Native. We haven't been able to take enough care of open source requests around react-native-packager because of the sheer size of the react-native repository. We know there are a couple of long-standing issues and we'd like to finally address them in a smaller codebase that is easier to contribute to and easier to maintain:

  • Make it easier to configure react-native-packager.
  • Symlink support.
  • Ability to use custom transformations and languages.

What will change as a user of react-native?

Nothing.

What will change for maintainers of the react-native repo?

The new repository will require releases to be lined up with releases of react-native but we aim to make the publishing process simple.

What will change when sending Pull Requests to react-native?

Contributors will have to send pull requests to the new repository for react-native-packager.

What will change for engineers at Facebook?

We aren't changing our current workflow but we may change to use GitHub-first development for react-native-packager in the future.

Please let us know if you have any concerns. The team and I are happy to address them.

cc @davidaurelio, @jeanlauliac

@cpojer cpojer changed the title from Moving react-native-packager into a new repository. to [Discussion] Moving react-native-packager into a new repository. May 15, 2017

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer May 16, 2017

Contributor

Everybody seems to be happy, so I'm closing this. Feel free to comment on this thread if you have further thoughts.

Contributor

cpojer commented May 16, 2017

Everybody seems to be happy, so I'm closing this. Feel free to comment on this thread if you have further thoughts.

@cpojer cpojer closed this May 16, 2017

@jeanlauliac

This comment has been minimized.

Show comment
Hide comment
@jeanlauliac

jeanlauliac May 16, 2017

Contributor

Shouldn't we just keep this open until the migration is done?

Contributor

jeanlauliac commented May 16, 2017

Shouldn't we just keep this open until the migration is done?

@migueloller

This comment has been minimized.

Show comment
Hide comment
@migueloller

migueloller May 16, 2017

@cpojer,

I want to start off by saying thanks to you and the rest of the React Native team for all your great work!

I had a quick question, where does the RN team stand with regards to packager alternatives like Haul?

I'm curious if there would be a benefit in there being 1 "blessed" packager that could cater to the community's needs (i.e., symbolic links, latest HMR, Webpack's ecosystem, etc.). Are there features currently in the packager that can't be implemented in Haul? Would it take too long for Haul to reach feature parity with the packager?

I'm curious as to what the RN team's thoughts are on these.

migueloller commented May 16, 2017

@cpojer,

I want to start off by saying thanks to you and the rest of the React Native team for all your great work!

I had a quick question, where does the RN team stand with regards to packager alternatives like Haul?

I'm curious if there would be a benefit in there being 1 "blessed" packager that could cater to the community's needs (i.e., symbolic links, latest HMR, Webpack's ecosystem, etc.). Are there features currently in the packager that can't be implemented in Haul? Would it take too long for Haul to reach feature parity with the packager?

I'm curious as to what the RN team's thoughts are on these.

@jeanlauliac

This comment has been minimized.

Show comment
Hide comment
@jeanlauliac

jeanlauliac May 16, 2017

Contributor

As for my own opinion, being working on packager, I'm happy there are alternatives such as Haul so that the community has more options depending on needs such as symlinks. I believe this is healthy for React Native to have alternative choices.

I think one of the main difference right now is performance, where Metro bundler/packager achieve higher incremental build performance. That makes sense as it's the reason we built it in the first place, but it also explains the limitations such as not supporting symlinks—we depend on watchman, that doesn't support these. That is why I think feature parity is not necessarily achievable or desirable, but that it doesn't mean we can't share a large amount of features and/or code ^_^

My wish is that anyone can break apart the code of packager and reassemble it in different ways so that there are never hard a constraint on what is or isn't possible.

EDIT: btw I stumbled on that old thread, linked from the packager/README.md, that describes the early differentiation: #5

Contributor

jeanlauliac commented May 16, 2017

As for my own opinion, being working on packager, I'm happy there are alternatives such as Haul so that the community has more options depending on needs such as symlinks. I believe this is healthy for React Native to have alternative choices.

I think one of the main difference right now is performance, where Metro bundler/packager achieve higher incremental build performance. That makes sense as it's the reason we built it in the first place, but it also explains the limitations such as not supporting symlinks—we depend on watchman, that doesn't support these. That is why I think feature parity is not necessarily achievable or desirable, but that it doesn't mean we can't share a large amount of features and/or code ^_^

My wish is that anyone can break apart the code of packager and reassemble it in different ways so that there are never hard a constraint on what is or isn't possible.

EDIT: btw I stumbled on that old thread, linked from the packager/README.md, that describes the early differentiation: #5

@cpojer

This comment has been minimized.

Show comment
Hide comment
@pie6k

This comment has been minimized.

Show comment
Hide comment
@pie6k

pie6k Jun 8, 2017

I think it'd be nice to write key this key sentence from here: 'What will change as a user of react-native? Nothing.' on Metro repository readme. I was looking few good minutes for some docs about 'how to switch to metro' :)

pie6k commented Jun 8, 2017

I think it'd be nice to write key this key sentence from here: 'What will change as a user of react-native? Nothing.' on Metro repository readme. I was looking few good minutes for some docs about 'how to switch to metro' :)

@jamesreggio

This comment has been minimized.

Show comment
Hide comment
@jamesreggio

jamesreggio Jun 15, 2017

Contributor

The impact on React Native users isn't quite zero — in fact, this is a breaking change.

The iOS pbxproj generated by react-native init includes a 'run script' build step that invokes the following shell command:

export NODE_BINARY=node
../node_modules/react-native/packager/react-native-xcode.sh index.ios.js

Now that /packager is gone and react-native-xcode.sh now lives under /scripts, existing React Native users will have to update the path in this build step.

There's a lot of different PRs and commits supporting this switch, so perhaps I didn't see the Breaking Change announcement. Either way, I strongly recommend you include it in the release notes for 0.46.


tl;dr for other people in search of a solution:

If you're seeing this error during iOS builds...

../node_modules/react-native/packager/react-native-xcode.sh: No such file or directory

...then you need to go into Xcode, click the root of your project, go to 'Build Phases', find the one that says 'React Native', then update the command to point to:

export NODE_BINARY=node
../node_modules/react-native/scripts/react-native-xcode.sh index.ios.js
Contributor

jamesreggio commented Jun 15, 2017

The impact on React Native users isn't quite zero — in fact, this is a breaking change.

The iOS pbxproj generated by react-native init includes a 'run script' build step that invokes the following shell command:

export NODE_BINARY=node
../node_modules/react-native/packager/react-native-xcode.sh index.ios.js

Now that /packager is gone and react-native-xcode.sh now lives under /scripts, existing React Native users will have to update the path in this build step.

There's a lot of different PRs and commits supporting this switch, so perhaps I didn't see the Breaking Change announcement. Either way, I strongly recommend you include it in the release notes for 0.46.


tl;dr for other people in search of a solution:

If you're seeing this error during iOS builds...

../node_modules/react-native/packager/react-native-xcode.sh: No such file or directory

...then you need to go into Xcode, click the root of your project, go to 'Build Phases', find the one that says 'React Native', then update the command to point to:

export NODE_BINARY=node
../node_modules/react-native/scripts/react-native-xcode.sh index.ios.js
@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Jun 15, 2017

Contributor

cc @grabbou – would you mind including this in the Release Notes? We weren't aware that generated files would have full paths.

Contributor

cpojer commented Jun 15, 2017

cc @grabbou – would you mind including this in the Release Notes? We weren't aware that generated files would have full paths.

@grabbou

This comment has been minimized.

Show comment
Hide comment
@grabbou

grabbou Jun 16, 2017

Collaborator

Makes a lot of sense! We will include those in release notes as soon as we finish working on them :)

Collaborator

grabbou commented Jun 16, 2017

Makes a lot of sense! We will include those in release notes as soon as we finish working on them :)

@peterp

This comment has been minimized.

Show comment
Hide comment
@peterp

peterp Jul 15, 2017

Contributor

@grabbou I couldn't find this in the release notes?

Contributor

peterp commented Jul 15, 2017

@grabbou I couldn't find this in the release notes?

@grabbou

This comment has been minimized.

Show comment
Hide comment
@grabbou

grabbou Jul 17, 2017

Collaborator

That's right! Now should be there :)

Collaborator

grabbou commented Jul 17, 2017

That's right! Now should be there :)

matthamil added a commit to matthamil/react-vr that referenced this issue Aug 8, 2017

Changed link for the React Native Packager
The React Native packager no longer exists at the previous location linked in ReactVROverview.md. The packager, now named Metro Bundler, is now a stand-alone repo. See facebook/react-native#13976.

facebook-github-bot added a commit to facebook/react-360 that referenced this issue Sep 5, 2017

Changed link for the React Native Packager
Summary:
The React Native packager no longer exists at the previous location linked in ReactVROverview.md. The packager, now named Metro Bundler, is now a stand-alone repo. See facebook/react-native#13976.

## Motivation (required)
The link for the React Native packager directs to a 404 page not found. The link has been updated to reflect the new home for the packager i.e. the Metro Bundler, which is it's [GitHub repo](facebook/react-native#13976).

## Test Plan (required)

Click the previous link ([here](https://github.com/facebook/react-native/blob/master/packager/README.md)) and see that it 404s. :)
Closes #301

Reviewed By: mikearmstrong001

Differential Revision: D5763923

Pulled By: mikearmstrong001

fbshipit-source-id: 2587e58

@facebook facebook locked as resolved and limited conversation to collaborators May 24, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.