-
Notifications
You must be signed in to change notification settings - Fork 24.3k
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
[Packager] should use compatible versions of node core modules #1871
Comments
Seems reasonable... this might have to be community driven, if you were to submit a PR it would be very helpful to get this moving along further |
Could you define a set of polyfills and require them from your index.js file? Seems simpler and more amenable to evolution to me. |
@ide The problem is when some module deep in your dependencies does e.g. |
@brentvatne I'm not familiar with Packager's internals, any pointers for where this should go? |
@quarterto - unfortunately I'm very much in the same boat as you |
+1, would appreciate a pointer for where in packager it would be best to do this. I would love for react-native to accept a "fallbacks" mapping, i.e. if some module does require('fs'), and 'fs' can't be resolved, check fallbacks. Browserify and webpack currently (unfortunately) make the choice for you with core module fallbacks, so if you want to add some that are missing (fs, dgram, net, a few others), or choose different fallbacks for a different environment -- browser vs chromeapp vs react-native, etc. -- there's no convenient way. I'm currently using react-native-webpack-server and a fork of node-libs-browser that adds fs, dgram and others. It works, but it's not terribly convenient. I'd prefer to be able to use react-native's packager. Edit: correction, browserify does allow you to pass in alternative builtins |
@amasad maybe you're the one to give us a hint? :) |
hey @mvayngrib. Currently, we only support "script polyfills". Meaning they run before the Also, FYI, we're moving the packager to it's own repo some time soon, so I'll ping you to move the discussion there. |
+1 |
A more detailed discussion here #6253. To keep issues more focused, I'm closing this in favor of discussion there. @amasad @mvayngrib feel free to reopen here or discuss there. |
Set the contents of /**
* Copyright (c) 2015-present, Facebook, Inc.
* All rights reserved.
*
* This source code is licensed under the BSD-style license found in the
* LICENSE file in the root directory of this source tree. An additional grant
* of patent rights can be found in the PATENTS file in the same directory.
*
* @providesModule path
*/
module.exports = require('../../node_modules/path-browserify'); This technique can be applied generically. Any thoughts? |
Many npm modules are currently not compatible with React Native because they depend on node's core modules. A good example of such a module is
through
, which depends on thestream
module, and has nearly 1500 modules that depend on it. Currently, if a module likethrough
is depended on, you get a slightly opaque runtime error such asRequiring unknown module 'stream'
, with no further information.Browserify uses various npm modules in place of node core modules. I guess Webpack must be doing something similar.
Ideally, I'd like to see:
What do you think?
The text was updated successfully, but these errors were encountered: