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 :wink:

[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

[jeffcressman]

@radubrehar I've been trying to figure out how to use browserify polyfill node modules with React Native and have landed on this project. You might find this thread useful as it discusses some reasons RN isn't using Webpack in addition to @amasad's comment that

Users should be able to choose their own module systems and bundlers (or not use bundlers if they want).

So far this project is looking like the best option for integrating Loopback isomorphic javascript into a RN app. The Loopback code is presently intended to be compiled with Browserify.

[radubrehar]

@jeffcressman thanks for the clarifications and context. I totally agree everyone should be able to use their own module system & bundler. I'm using webpack extensively for React for more than 1.5 years now but am new to React Native, so sorry if the following question is too basic: is there a proved way to bundle files with webpack and then feed the output bundle into the RN bundler?

[changfuguo]

ye, i am using rnws; because i just want to depart the lib code and app logic code;

for the app development, i dot think hot reload is the frist important thing,

[jacobrosenthal]

Personally the only real reason I need react-native-webpack-server is resolve.alias

@radubrehar and others looking for resolve.alias support in react native packager, I created a product pains (which is how react native wants to track issues now?) if you want to +1 that https://productpains.com/post/react-native/packager-support-resolvealias-ala-webpack/

[ThaJay]

ProductPains seems like a lot of work for very little, can't even browse existing issues, so it seems useless compared to GitHub issues. ayway, having a settings file like webpack.config.js or .babelrc would be suitable, but even better in my opinion would me to just accept the basics in the packager and let us worry about the rest.

I'm going to try and have webpack output (ES5) to the file RN bundler reads. weren't there some issues with resolving native dependencies that prevent this? solving these so webpack can just bundle and RN bundler can just serve (and be renamed to server) seems like a better idea.

[elliottsj]

@ThaJay Yes, IIRC, the reason we can't feed webpack's output into the RN bundler is that webpack doesn't understand Facebook's haste module system (https://github.com/facebook/react-native/issues/5#issuecomment-72341589). Work is being done towards allowing any CommonJS bundler to be used in place of the RN bundler (https://github.com/facebook/react-native/commit/8d397b4cbc05ad801cfafb421cee39bcfe89711d), though I'm not sure about the current progress of this.

[ThaJay]

for anyone still looking to use webpack, this externals function looks up react-native modules so webpack won't get in the way of RN-Packager. https://gist.github.com/alexesDev/071f8935c82ca87a5b46

[tristangodfrey]

I'm pretty sure it's impossible to avoid "../" hell in react-native without applying a horrible hack, or am I completely wrong here? https://github.com/facebook/react-native/issues/637

[ThaJay]

uninstall Watchman + don't use Windows. I should be okay now on Ubuntu using Node filewatcher with symlinks. RNPackager really needs proper aliasing...

edit: Using Ubuntu with watchman without symlinks. We split up all the platforms in separate projects and put the common code in a submodule. Only downside is I have our core copied in each repo folder on disk.

[jacobrosenthal]

@gaearon Any love from facebook on resolve alias of more than 1 level deep?

[gaearon]

Unfortunately I don’t understand the problem well enough and don’t work on the packager either.

[jacobrosenthal]

Can I beg for a poke to that team for your previous love of this project :) We would get bluetooth (via the noble api) in react native as a result :)

On Sun, May 1, 2016 at 7:02 PM, Dan Abramov notifications@github.com wrote:

Unfortunately I don’t understand the problem well enough and don’t work on the packager either.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/mjohnston/react-native-webpack-server/issues/143#issuecomment-216080033

[gaearon]

Can you help me understand the problem better?

[jacobrosenthal]

@gearon Absolutely Hopefully @elliottsj and @philikon can explain what they need to keep react-native-webpack-server in the ecosystem.

For the rest of us stuck in the middle of the two, webpack has a key feature missing/half implemented in the react native packager. Rather than further squatting this thread I posted a follow up on my existing product pains: https://productpains.com/post/react-native/packager-support-resolvealias-ala-webpack/

Thanks for listening.

On Sun, May 1, 2016 at 8:20 PM, Dan Abramov notifications@github.com wrote:

Can you help me understand the problem better?

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/mjohnston/react-native-webpack-server/issues/143#issuecomment-216083729

[philikon]

@gaearon we need webpack mostly because the RN packager

• does not support symlinks
• doesn't do browserify or module aliases, as described by @jacobrosenthal
• its dependency resolution does not scale well for large node_modules trees

[scriptjs]

We can help get to what we want by supporting the move to migrate Haste into proper libs (consumable as node modules and that are distributed with react-native) and getting the packager extracted from react-native itself. I would suggest it is important to oppose any direction that would see perpetuating the use of Haste in expanding react-native's capability with platforms. If Haste is used in the original sources but converted to libs for use with node as proper node modules this would be acceptable.

A recent commit to provide Windows support suggests they would like their code to be an exception but this cannot be permitted. See https://github.com/facebook/react-native/pull/7639. While the expanded platform support is welcome, we need to get to the state where we are no longer concerned with Haste in our projects.

https://github.com/facebook/react-native/issues/7636 https://github.com/facebook/react-native/issues/7668

The pain in the project is largely the result of Haste and the fact we are forced into the packager as the result of this. If the packager were on its own, we'd be getting to the place that we could use whatever packaging and bundling solution we want.

Please add your voices or work to the above issues since this is what will bring an end to the kludge and we finally we can build, bundle and package in direct way with the tooling we want to use.

[afilp]

Hello,

in a pure React project I can do "conditional" compiling for different apps with the same code base, by using webpack as such:

I want to do the same with React-Native apps, i.e. create 3 different apps based on a single common code base. At least for the part of the JavaScript bundle (if for the native wrapper is difficult to do such).

How would I do this if I do not have access to webpack?

Thanks!

[ThaJay]

@af7 I have been working on that question a few months ago. Due to the lack of aliasing and symlink support in packager, but the general lack of actually working with react-native in webpack we decided on the following solution:

All common code goes in a core repo that is imported using git submodules functionality. We make a separate repo for each platform with the following structure, where the core folder is our submodule:

app-name-platform-name
| core/
| | components/
| | helpers/
| | settings/
| | | development.js   (envSettings.js points to one of these,
| | | production.js    the rest is imported normally)
| node_modules/
| src/
| | platformhelpers/
| | subcomponents/
| | viewcomponents/
| | index.js
| | react.js
| | envSettings.js symlink (it's followed, not watched. fine for things that don't change)
| static/
| index.android.js etc...

then in index.android.js:

import React, {AppRegistry} from 'react-native'
import {AppWrapper} from './src/index.js'

AppRegistry.registerComponent('appname' () => AppWrapper)

in react.js:

const React = require('react-native')
module.exports = {React}

so we can import either react or react-native with one change. it's old syntax becaus of issues with re-export / re-require when using import

it's not the nicest solution because there's a copy of core in each repo, but at least it works without a thousand quirks.

If you were to use react-native-web you would even be able to write most of the view layer for multiple platforms.

note that react-native init does not work with - as word separator.

[philikon]

Hey folks. After a lot of struggling, I have moved off of react-native-webpack-server. Like a lot of folks here, the only reason I was using it was to use code written for node.js inside my React Native app. In other words, webpack's ability to browserify my code, resolve module aliases, etc. Rather than maintaining react-native-webpack-server, which has always been behind on things like hot reload, debugging, etc., I've worked on a way to get the features I needed using the regular React Native packager.

Please check out https://github.com/philikon/ReactNativify. Would love feedback from folks, ideally in the form of PRs.

Also, in case it's not clear yet, I no longer plan on maintaining react-native-webpack-server.