Add prebuilt library to react-native NPM package (for webpack / browserify)

[pilwon]

I'm trying to build JS bundle with webpack and serve my custom bundle at http://localhost:8081/index.ios.bundle with webpack-dev-server. I'm willing to make a tradeoff of build speed for cross-project code reusability. (For example, I like using babel as my ES6 transpiler as it supports much richer es6 feature set than jstransform that default packager uses. I'd like to write react-native apps with the same ES6 features)

The problem arises when webpack fails to resolve react-native defined internal module names since webpack doesn't understand the flattened internal names. Manually mapping using resolve.alias feature of webpack is one way but there are simply too many of them and it's too much work to track changes in every future version releases.

To simplify this process, please consider adding prebuilt JS binding portion of react-native library to NPM published package. Also, it'd be also nice to add an option to the built-in packager cli so library bundle can be conveniently rebuilt with local changes.

[amasad]

I don't think that's the greatest solution. Having many npm packages will make versioning really hard. Unfortunately I don't have better ideas for now. But I'm sure we can come up with something better.

[jaygarcia]

I disagree that putting in a pre-built static library is a good thing. I enjoy the ability to dive into the source code for RCT and I see it as a valuable asset.

JG

:: sent from my mobile device ::

On Mar 26, 2015, at 19:42, Amjad Masad notifications@github.com wrote:

I don't think that's the greatest solution. Having many npm packages will make versioning really hard. Unfortunately I don't have better ideas for now. But I'm sure we can come up with something better.

—
Reply to this email directly or view it on GitHub.

[pilwon]

@jaygarcia: I disagree that putting in a pre-built static library is a good thing. I enjoy the ability to dive into the source code for RCT and I see it as a valuable asset.

The proposal was to add prebuilt JS bundle of react-native to NPM package. (only the pre-compiled JS binding, not a new static Obj-C library to replace RCT* libraries)

[pilwon]

@amasad I agree there must be a better solution. At best, the proposed solution above serves as non-breaking, temporary hack until webpack/browserify is officially supported by react-native.

If it's too much work to maintain official prebuilt JS releases, would it be possible to add an option to the built-in packager cli for clean local builds at least? That way webpack/browserify users can start experimenting with their preferred setups until react-native team comes up with a better solution.

[joewood]

I think a prebuilt package solves a few problems:

• Ability to use other transforms (Coffee, TypeScript etc..)
• Ability to run on other platforms (currently watchman and the packager is OSX only)
• Integrate with existing projects that already use WebPack or Browserify

I can't see a downside, as there would only be one released version on npm.

[joewood]

This issue brought up previously, #146 and #133

[yaru22]

I do also use webpack and it would be great to have an option to build the bundle using webpack. As @pilwon mentioned, if you can include pre-built JS for webpack to resolve modules properly, that would help webpack community a lot!

[amasad]

A better approach is building a webpack loader and resolver that delegates to the React Native packager. This way webpack can process your files but will delegate to the packager for things it can't find, i.e. the core libraries. Any takers? should be a fun project.

[joewood]

Just to confirm, the resolver is simply recursing down from root to locate the package/module, right? Then it would be just a matter of applying the JSXTransformer. I tried this a couple of weeks ago, but wasn't making much progress. I was hitting duplicate module problems from the root.

[amasad]

the resolver is simply recursing down from root to locate the package/module, right?

yes

Then it would be just a matter of applying the JSXTransformer

I don't know what you mean here. You mean on webpack's side?

I tried this a couple of weeks ago, but wasn't making much progress. I was hitting duplicate module problems from the root.

It'd be useful to share more details, like error messages, what exactly you've done etc.

[joewood]

Sure, I'll put up what I did later. What I mean is that the require("xxx") in the react-native code needs to locate the module, and it does that in a dir-layout agnostic way by recursively descending down the directory structure looking for JS files with the providesModule directive. That's what I gleaned from the source code, so I could be completely on the wrong path.

[pilwon]

I tried implementing @amasad's idea and here's what I've got so far. It successfully reads module dependencies information asynchronously with packager and then it constructs an alias map in the format webpack's ModuleAliasPlugin uses. I need help from the community getting this alias map to extend resolve.alias (or something similar). The code for this is there but I believe I'm doing something wrong with this.doResolve. It hangs. (webpack's resolver plugin API is a mystery to me)

I also tried hard-coding the above alias map in the webpack config file. When you assign the alias map merged with {CSSVarConfig: 'react-native/Libraries/Utilities/CSSVarConfig'} (missing from the above result for some reason) to resolve.alias, it succesfully builds a bundle file with a warning message but there's an error in app runtime complaining document variable is undefined. Playing with output.library and output.libraryTarget didn't help. It'd be better to fix the above first since hard-coding approach is not easily maintainable with future version releases of react-native.

[pilwon]

I decided to settle on this solution for now. It only overrides react-packager's transformer. You can run any combination of transpilers with that approach. It seems like a better solution if using custom transpiler is all you want with webpack/browserify.

[pilwon]

Closing this issue as this approach solves my problem. I no longer see a need for adding prebuilt react-native JS bundle to NPM.