Looking for a maintainer

[elliottsj]

Hey guys,

I've tried to keep RNWS up-to-date and not broken in the past weeks, but unfortunately I can't dedicate much time to it these days since I'm no longer actively using the project. There's quite a bit of work to be done to get RNWS up to parity with the RN packager (and to get hot reloading to work with the recent RN versions); if you'd like to help out with these things, I'm happy to accept pull requests, and I'm sure @mjohnston would be happy to grant push access.

cc @amccloud

With that said, use this project at your own risk 😉

[gaearon]

Now that RN supports Babel, it seems like the only differentiating feature of RNWS is hot reloading. Therefore it's probably easier to work on adding hot reloading to RN than playing catch up with RN after every release.

[elliottsj]

True, HMR is probably the biggest reason to use RNWS. The other big thing that RNWS provides is access to webpack's loader & plugin ecosystem (e.g. for CoffeeScript support), but I'm not sure how valuable that is to most people.

[jrm2k6]

Is there already some work being done to add Hot Reloading to RN?

[philikon]

The reason why I still use RNWS is the ability to have browserify polyfill node modules. I need to run a fair bit of code inside React Native that's shared with other clients running node, not to mention using a bunch of upstream node libraries that Just Work(tm) thanks to browserify.

Also, while the React Native packer now uses babel, it's not actually possible to supply your own .babelrc. Its baked into the transformer, which btw executes way before the dependency resolver. So it's hard to polyfill certain modules without actually physically putting them in your node_modules tree. And not being able to customize .babelrc means you're at the mercy of React Native in terms of what transforms and ES2015 features you can use in your code.

[jordaaash]

Also, while the React Native packer now uses babel, it's not actually possible to supply your own .babelrc. Its baked into the transformer, which btw executes way before the dependency resolver.

This.

I use a custom babel transform whitelist, and I actually do use RNWS for the Webpack loaders and plugins (eslint, and especially DefinePlugin is really nice for building development/staging/production versions of the app). The file loader is also really useful for adding static assets to the project, combined with venmo/synx.

I don't even use it for HMR.

[mjohnston]

Given that Dan and Sebastian are both working on FB infrastructure now, I'll second Dan's recommendation of adding these features to RN rather than play catch-up here.

[philikon]

Given that I will depend on rnws for the foreseeable future, I'd be happy to take up a role as (co-)maintainer. My needs only cover a subset of features (for instance, I don't care much about hotloading -- yet?). Also I believe in critical code review. So I think it'd be good if there was at least one other peer who's actively using the code in their project and can review changes. Any takers?

[mjohnston]

Seeing as I don't use this project anymore myself I'm happy to transfer or grant push access to others who rely on it and are willing to maintain it.

That being said, I believe the best outcome would be for RN to support the features that compel people to use RNWS - namely alternate bundlers and/or hot reloading.

[philikon]

That being said, I believe the best outcome would be for RN to support the features that compel people to use RNWS - namely alternate bundlers and/or hot reloading.

I agree wholeheartedly, as I'm sure would @amasad et.al. I think the best outcome for RNWS's future would be to push as much of the "React Native external" parts into React Native itself, so that ultimately using webpack as a packager just boils down to writing a webpack.config.js. I'd be happy to drive that effort, but it depends a bit on what the folks at FB have in mind for the packager in the near to mid-term.

[amasad]

Actually @sebmarkbage and I were just chatting about this the other day -- I think that ultimately Facebook's requirements will always be different. So RN should just provide the basic API and environment through globals (just like the browser does) and get out of the way. Users should be able to choose their own module systems and bundlers (or not use bundlers if they want).

[philikon]

I like that plan a lot. Is Facebook's ecosystem (and thus React/React Native) in the long run going to adopt the node module system, or is Haste sticking around? Currently that seems to be the biggest source of awkwardness for bundling React Native code.

[amasad]

I should clarify, it's not really a plan, that's just my opinion. I'm not currently as involved as I'm working on a different project. cc @martinbigio who is currently working on the RN packager.

Is Facebook's ecosystem (and thus React/React Native) in the long run going to adopt the node module system, or is Haste sticking around? Currently that seems to be the biggest source of awkwardness for bundling React Native code.

Haste is sticking around internally, people find tremendous value in using it. However, this is partly why I think FB's requirements will always be different. One of the things I tried really hard to do with the React Native packager is to shelter the community from Haste since node modules work really well in open source. But, you'll still run into it if you're doing any infra work for RN.

[radubrehar]

I think webpack has some really nice features that are useful for apps. For example, resolve.alias, resolve.modulesDirectories and a few others. Since most React web apps are built using webpack, would it not be a good idea for RN to switch to webpack in the first place? This would help unify a bit the building step for both React and RN.

[braco]

I too was using RNWS solely for the utility webpack brings.

[radubrehar]

@braco glad there's someone who sees value in this