[Packager] Publish as a standalone NPM module

[pilwon]

It'd be nice to publish react-packager as a standalone NPM module.

[amasad]

We plan to do that, this will solve #341

[jsierles]

Is this in the works or should I take a look at packaging it?

[amasad]

@jsierles no. Go for it!
I'd like to know your use case, I'm curious.

[jsierles]

For the React Native Playground, we're running the packager along side different versions of React Native. Having the packager separate would make it easier to test changes there without having to upgrade react-native itself, and vice-versa.

[amasad]

I tried to keep it as decoupled as possible, so it shouldn't be too hard. Happy to help.

[paramaggarwal]

Yes, this would be great. I would like to add this as an Xcode build phase, that simply creates a jsbundle to add into the app bundle when doing an Archive build. With a separate packager, I don't need to run the server, wait for it to be ready and then curl the bundle from it.

[jsierles]

Been looking at this. It looks like the packager is already setup to be published as a module. A few doubts:

• Should it be split out to a separate repository?
• Do we need to change anything besides the RN sample app?

[jsierles]

@paramaggarwal By the way, you can bundle that way today using 'react-native bundle' at the root of your project.

[paramaggarwal]

@jsierles Oh, that would be great. I'm seeing this error:

$ npm install -g react-native-cli
/usr/local/bin/react-native -> /usr/local/lib/node_modules/react-native-cli/index.js
react-native-cli@0.1.4 /usr/local/lib/node_modules/react-native-cli
└── prompt@0.2.14 (revalidator@0.1.8, pkginfo@0.3.0, read@1.0.6, winston@0.8.3, utile@0.2.1)
$ react-native bundle
Command `bundle` unrecognized. Did you mean to run this inside a react-native project?

I tried running it inside my project. I also don't see any mention of the bundle command inside the react-native-cli code here.

[jsierles]

It needs to be run from inside your project. The global cli loads a local cli which provides the bundle command.

https://github.com/facebook/react-native/blob/master/local-cli/cli.js

[paramaggarwal]

Ah, I see. Unfortunately that local-cli directory is not available when installed via Pods - it probably needs to be in preserve_paths in the pod spec. Will raise separate issue for that, thanks.

[amasad]

Yes, we wrote in isolation but it made the syncing process a lot easier to be coupled with react-native. Isolating into it's own repo needs some changes internally. I'm taking some time off in July but I can start looking into this in August. We'll also start using parts of the packager in other projects.

[jsierles]

Sounds good! For now, isolating it in npm would be a good step, I'll be looking at that during July. In general, for rnplay.org we're trying to work out some better solutions for running multiple packagers with multiple entry points each. What would be a good place to discuss this?

[amasad]

I think here is as good as any. Can you expand on more on your requirement? What can be better about it?

[jsierles]

It may be too ambitious, but we'd like to have a packager running for each version of React Native, and have each one of those serving multiple apps. This works today, by using a single copy of react native at one root, and the applications all at another.

But this slows down as more and more application data gets cached in the packager. I also assume that if multiple apps require packages with the same name, they could conflict in the packager cache. This has happened when more than one react-native copy gets installed in one of the app's node_modules. And, as more apps get created with complex dependencies, I figure file watching for entire node_modules trees will not scale.

It would be great to know if there's a better way to optimize this use case, and where we should be looking to help improve the packager.

A few ideas I had to help this:

• Shard apps across multiple packagers per react-native version to keep the cache size down
• bundle an apps node_modules into a single file, required by the app, since these files wont be edited and don't need to be crawled

[amasad]

Good news, we're moving the packager to it's own npm package and github repo. Should release very soon.