Given "crypto-browserify": "~3.2.6",

Bundled (React) Webpack output errors with: 'Uncaught ReferenceError: _crypto is not defined'

This is I believe fixed in crypto-browserify 3.9.14

crypto-browserify/crypto-browserify@30d96df

Any chance of an update?

Browserify has stopped using http-browserify and moved to stream-http which actually supports true response streaming and has lots of bug fixes.

webpack should probably switch over too.

This would fix this bug when WebTorrent is built with webpack.

cc @jhiesey

#64

I am bringing in webpack via npm, and when I try to commit my node_modules, I get the following error:

fatal: Not a git repository: /Users/Mathias/Projects/punycode.js/.git/modules/vendor/docdown

Essentially, the node_modules/webpack/node_modules/node-libs-browser/node_modules/url/node_modules/punycode/vendor/docdown directory has a .git file in it. It looks like this problem has been fixed in newer versions. However, node-libs-browser is using an older version of the url package that has this problem.

I tested this by creating a new directory and running:

npm install [email protected]

If I instead do:

npm install url

there is no problem.

I think that bumping the version from ~0.7.9 in the package.json to ~0.10.1 would resolve this issue. I'd be happy to submit a pull request but I'm not sure how to verify this doesn't break anything.

When an event listener is removed the EventEmitter class should fire the "remoteListener" event.

This was added in Node.js 0.10, see:

nodejs/node-v0.x-archive@84221fd

Please let me know if this feature is desired and if so I'll gladly provide a pull request.

would something like this work? https://www.npmjs.com/package/mock-fs

@webpack

This repo would ideally give a bit more details in the readme, for easy reference.

• which modules are implemented (for example, 'process') and which are not (for example, 'fs')
• how the implemented modules differ from their node counterparts

I would gladly volunteer to take this task if it pleases you.

I'll note that it's of particular importance to me that the browser member of process (i.e. process.browser) gets documented. It would be a brief mention, and I would by no means go into details or examples of how to use it, but I will breifly argue it's significance to you here...

You can reference process.browser in isomorphic code that

• adjusts it's behavior depending on which environment it's in
• is fully portable within the nodejs/iojs/browserify/webpack ecosystem, and
• is concise and Don't Repeat Yourself (DRY)

That said, I intend on doing a thorough documentation of each module, not just process, should you welcome my offer to help.

So, I guess my question is: Would you like to see a PR with enhanced documentation as described?

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
After compiling a bundle with deps which use os.homedir function (for example is-reachable) i've got the error in the runtime: Uncaught TypeError: os.homedir is not a function
In the bundle os.homedir is undefined.

What is the expected behavior?
os.homedir shoud be a function

Please update os-browserify package to the latest version (0.3.0) to get support of os.homedir function in bundle.

This issue was moved from webpack/webpack#5512 by @sokra. Orginal issue was by @Deadly0.

It fixed a SHA bug (browserify/sha.js#4)

Note the 3.0 series doesn't support the weak Math.random any more, it relies on getRandomValues so won't work on older browsers.

The buffer module currently used (v4) performs a check of a variable explicitly on the global variable, something like if(global.TYPED_ARRAY_SUPPORT). As mentioned in #31, global is not polyfilled—at least it isn’t when building a Webpack bundle for the webworker target. As a result, code that relies on Webpack polyfilling the buffer module will break in webworkers.

This can be trivially fixed by updating to the latest version of the buffer module (5), but in #45 it seems that sticking to an older version is a deliberate decision.

npm install --save node-libs-browser?

Can this info be included in the readme?

Currently events is polyfilled with gozala/events. However, it is far behind the latest Node version, and perhaps more concerningly its unit tests are failing and they are not run in a wide array of browsers, so upgrading it is dangerous (though I have a PR in to do so).

Unfortunately it doesn't look like there's other solid isomorphic event implementations which match the Node API, at least none that my Google-fu could find. I would be happy to spend a weekend getting something drafted up if there's interest in updating this; an updated implementation to be tested both in Node via and in browsers via Browserstack or SauceLabs.

Calling a read function on the embedded buffer without any argument will throw an exception.
This is major incompatibility issue with node.js buffer.

Error message thrown: "RangeError: offset is not uint"

Corresponding issue: feross/buffer#237

I suggest to reconsider PR: #68, which does fix the issue

how to polyfill "require" ? should i otherwise " npm install events" when using "events" browser implementation?

Please update the crypto-browserify version of the dependent packages to the latest.
License of [email protected] of dependent packages of [email protected] is unknown.
It will be solved by the crypto-browserify to the latest version.

Hi,

to use recent readable-stream, I had to patch your module:

--- a/index.js
+++ b/index.js
@@ -22,11 +22,11 @@
 exports.readline                                       = null;
 exports.repl                                           = null;
 exports.stream                                         = require.resolve('stream-browserify');
-exports._stream_duplex                         = require.resolve('readable-stream/duplex.js');
-exports._stream_passthrough                    = require.resolve('readable-stream/passthrough.js');
-exports._stream_readable                       = require.resolve('readable-stream/readable.js');
-exports._stream_transform                      = require.resolve('readable-stream/transform.js');
-exports._stream_writable                       = require.resolve('readable-stream/writable.js');
+exports._stream_duplex                         = require.resolve('readable-stream/lib/_stream_duplex.js');
+exports._stream_passthrough                    = require.resolve('readable-stream/lib/_stream_passthrough.js');
+exports._stream_readable                       = require.resolve('readable-stream/lib/_stream_readable.js');
+exports._stream_transform                      = require.resolve('readable-stream/lib/_stream_transform.js');
+exports._stream_writable                       = require.resolve('readable-stream/lib/_stream_writable.js');
 exports.string_decoder                         = require.resolve('string_decoder');
 exports.sys                                                    = require.resolve('util/util.js');
 exports.timers                                         = require.resolve('timers-browserify');

I am looking to use my own polyfills/shims with Webpack

e.g.:

//webpack.config.js

node: {
 assert: require.resolve('oresoftware-assert'),
 fs: require.resolve('oresoftware-fs')
}

is this already supported? I don't believe I have seen this documented, but it would be a great feature, please advise

node-libs-browser is also affected by this issue browserify/diffie-hellman#22 but its author needs help. Can webpack team help?

The new version bump for process 0.10.x is causing sinon fake timers + bluebird + webpack to make all bluebird promises "freeze" (because it's now using setTimeout instead of the other method it used to (mutation/etc selection process had in 0.8)

Having a hard time figuring how how to undo this problem because webpack itself lists the dep on node-libs-browser to be ~0.4.0 and the bump here is definitely causing problems in all of our test suites that use sinon + bluebird.

code: MissingDateHeader 需要配置什么 文件吗

The nextTick polyfill is supplied by https://github.com/defunctzombie/node-process/blob/master/browser.js which uses timers. See: defunctzombie/node-process#86.

Because timers are often throttled when a tab is not active to improve battery life, they only run at 1Hz (once every second). This has a drastic performance impact in those scenarios.

It seems that the author won't change this for the time being, see: webtorrent/webtorrent#1568 (comment)

It would be cool to just map nextTick to setImmediate, as we are already providing that polyfill.

Hi
I'm currently using latest stable version of webpack (1.13.0) that relies on "node-libs-browser": ">= 0.4.0 <=0.6.0" which in turn uses "buffer": "^3.0.3". Any chance of bumping that up to utilize buffer 4.3.0 that's used by node-libs-browser v1.0? I'm running into an issue that was resolved in buffer since 3.0.3 and would prefer not to edit the buffer source under node_modules manually on x of the build machines.

What does this error mean, and how do I resolve it?

TypeError: The "original" argument must be of type Function
    at promisify (util.js?eed9:602)
    at Object.eval (index.js?b048:9)
    at eval (index.js:277)
    at Object../node_modules/readdirp/index.js (printable.js:5067)
    at __webpack_require__ (runtime.js:854)
    at fn (runtime.js:151)
    at Object.eval (index.js?b44e:7)
    at eval (index.js:942)
    at Object../node_modules/chokidar/index.js (printable.js:1206)
    at __webpack_require__ (runtime.js:854)

In my js file I have:

var fs = require('fs');

when I tried fs.readFileSync(..somefile);

Error is: fs.readFileSync is not a function

Is there any setup needed?

There is a new version of the browserify-zlib shim to zlib available at https://github.com/ipfs/browserify-zlib, it fixes some bugs and more importantly, it adds support for dictionaries.

It seems that not a lot of people use that feature, but it is essential for libp2p-spdy in the browser, which is part of js-libp2p and js-ipfs. Right now we are replacing the shim in our build tool, but it would improve the experience a lot if everyone using it could just rely on webpack to use the correct version of the shim.

We've a open PR -- browserify/browserify-zlib#18 -- to the bundled browserify-zlib in browserify, but 8 months have passed since it was open, the author and maintainer seems to be lacking the time to review. What else an we do to move this forward?

Thank you :)

There is also an issue open on browserify for this: browserify/browserify#1672 which suffers from the same problem.

cc @diasdavid

It's been a year since [email protected] was published in Nov 2017. I don't want to have to install this module from source just to get util.promisify. 😁

I encountered Error Uncaught TypeError: util.inherits is not a function while upgrading to webpack 2.

I traced the cause to the dependency "inherits": "2.0.1" instead of "^2.0.1" or the like in util, which is used by assert, which is used by node-libs-browser.

My current hideous workaround is adding to package.json:

"dependencies": {
  "inherits": "^2.0.3"

and to webpack.config.js:

resolve: {
  alias: {
    inherits$: path.resolve(__dirname, 'node_modules/inherits')

I also filed a bug with util at Outdated dependency inherits causes trouble upstream; Webpack 2.

Description

I create a app with create-react-app with --typescript, and add some lib to it. But when I execute start script, a compilation error has occurred:

Failed to compile.

./node_modules/browserify-zlib/lib/index.js
Module not found: Can't resolve 'util' in 'E:\sourcecode\frontend\AppDev-web\node_modules\browserify-zlib\lib'

I'm not explicit import browserify-zlib, so I search it in project, in yarn.lock file, I found this:

node-libs-browser@^2.0.0:
  version "2.2.0"
  resolved "https://registry.npmjs.org/node-libs-browser/-/node-libs-browser-2.2.0.tgz#c72f60d9d46de08a940dedbb25f3ffa2f9bbaa77"
  integrity sha512-5MQunG/oyOaBdttrL40dA7bUfPORLRWMUJLQtMg7nluxUvk5XwnLdL9twQHFAjRx/y7mIMkLKT9++qPbbk6BZA==
  dependencies:
    assert "^1.1.1"
    browserify-zlib "^0.2.0"
    buffer "^4.3.0"
    console-browserify "^1.1.0"
    constants-browserify "^1.0.0"
    crypto-browserify "^3.11.0"
    domain-browser "^1.1.1"
    events "^3.0.0"
    https-browserify "^1.0.0"
    os-browserify "^0.3.0"
    path-browserify "0.0.0"
    process "^0.11.10"
    punycode "^1.2.4"
    querystring-es3 "^0.2.0"
    readable-stream "^2.3.3"
    stream-browserify "^2.0.1"
    stream-http "^2.7.2"
    string_decoder "^1.0.0"
    timers-browserify "^2.0.4"
    tty-browserify "0.0.0"
    url "^0.11.0"
    util "^0.11.0"
    vm-browserify "0.0.4"

• I tried add util package, still not work
• I tried add util in webpack.config.js like this:

    node: {
      util: 'empty',
      module: 'empty',
      dgram: 'empty',
      dns: 'mock',
      fs: 'empty',
      net: 'empty',
      tls: 'empty',
      child_process: 'empty',
    },

still not work

Info

create-react-app: version: 2.1.8
webpack.config.js
package.json
tsconfig.json

Anybody know anything about this?

The version 0.5.3 of node-libs-browser currently depends on :

"crypto-browserify": "^3.2.6",

Which it self depends on [email protected] which was unlicensed.
This poses a problem for any webpack users since webpack uses version 0.5.3 of node-libs-browser.

Can you please release a new 0.5.4 version with crypto-browseriify 3.11.0 ?

This way, all sub licenses of webpack are conform with the license of webpack it self.

Currently used here [email protected]:

time node -e "require('path-browserify').extname(crypto.randomBytes(2 ** 23).toString('base64'))"
real    0m5.619s

Node 11 built-in path module:

time node -e "path.extname(crypto.randomBytes(2 ** 23).toString('base64'))"
real    0m0.133s

Latest [email protected]:

time node -e "require('path-browserify').extname(crypto.randomBytes(2 ** 23).toString('base64'))"
real    0m0.137s

Currently the fact that webpack pulls [email protected] via this module forces me to install [email protected] and alias it manually in webpack.config.js like this:

	resolve: {
		alias: {
			path: 'path-browserify',
		},
	},

I hope you can update it to 1.0.0.

EDIT: Turns out there is already a PR for this #79

Hello,

Looks like the update from a couple hours ago could be bringing in a bug with a downstream dependency.

Dependencies go:

• webpack 1.5.1 depends on node-libs-browser ~0.4.0
• node-libs-browser 0.4.2 depends on crypto-browserify ^3.9.13
• crypto-browserify 3.9.13 depends on diffie-hellman ^3.0.1
• diffie-hellman 3.0.1 breaks

Error in browser is: Cannot find module "./lib/primes", which is required from diffie-hellman/browser.js

Looks like there exists a ./lib/primes.json in that package, so maybe configuring webpack to auto check ".json" suffixes would work, I'll try that.

Will also learn about npm-shrinkwrap after this.

Any other tips for resolving issue? Thank you.

Should the xxx-browserify modules and authors merged into this package?

Pro:

• less fragmentation
• more maintainers for all node buildin libs
• easier sharing of small common fragments, i.e. shims
• easier to maintain

Contra:

• less modular
• "holy fuck. why are there 20 files and 1000s of lines of code in one repo"

Problems merging:

• xxx-browserify modules could not longer be used alone
  • they can transform into wrappers for this package

Problems splitting:

• duplicated effort to have each module tested in testling
• no aggregated test results
  • repo for aggregating results
  • badge wouldn't update

When running webpack-dev-server 1.9.0, we get the following errors from node-libs-browser:

ERROR in .//node-libs-browser//crypto-browserify/pbkdf2.js
Module not found: Error: Cannot resolve module 'pbkdf2-compat/pbkdf2' in H:\XXX\node_modules\node-libs-browser\node_modules\crypto-browserify
@ .//node-libs-browser//crypto-browserify/pbkdf2.js 1:19-50

ERROR in .//node-libs-browser//crypto-browserify/create-hash.js
Module not found: Error: Cannot resolve module 'sha.js' in H:\XXX\node-libs-browser\node_modules\crypto-browserify
@ .//node-libs-browser//crypto-browserify/create-hash.js 1:17-34

ERROR in .//node-libs-browser//crypto-browserify/create-hash.js
Module not found: Error: Cannot resolve module 'ripemd160' in H:\XXX\node_m
odules\node-libs-browser\node_modules\crypto-browserify
@ .//node-libs-browser//crypto-browserify/create-hash.js 4:27-47

ERROR in .//node-libs-browser//buffer/index.js
Module not found: Error: Cannot resolve module 'base64-js' in H:\XXX\node_m
odules\node-libs-browser\node_modules\buffer
@ .//node-libs-browser//buffer/index.js 8:13-33

ERROR in .//node-libs-browser//buffer/index.js
Module not found: Error: Cannot resolve module 'ieee754' in H:\XXX\node_mod
ules\node-libs-browser\node_modules\buffer
@ .//node-libs-browser//buffer/index.js 9:14-32

ERROR in .//node-libs-browser//buffer/index.js
Module not found: Error: Cannot resolve module 'is-array' in H:\XXX\node_mo
dules\node-libs-browser\node_modules\buffer
@ .//node-libs-browser//buffer/index.js 10:14-33

As mentioned here the current console polyfill is missing functions (such as, say console.table).

It would be nice if the polyfill was switched into something more current, like this one.

I did a quick research for breaking changes of outdated modules. This was necessary because it was unclear why @sokra chose to update to 1.0.0 for webpack 2 but not for webpack 1. This is the result:

Major version bumps (including 0.x changes)

buffer

Breaking change was feross/buffer@5daca86

@fanatid wrote:

v4.x uses Uint8Array by default and Object as shim
v5.x uses only Uint8Array and print error if TypedArrays not supported

Since we should still support IE9 and IE10 out-of-the-box, we should stick to v4 for now.

constants-browserify

The update should be no problem. Some constants have been changed but the usage is very unlikely.

https-browserify

No breaking change

os-browserify

No breaking change

readable-stream

Breaking change was nodejs/readable-stream@53ff397

Doesn't seem to be really breaking? readable-stream was not using semver prior v2.

stream-browserify

The funny thing is: stream-browserify is also using readable-stream for quite some time. We should just use readable-stream.

url

Possible breaking change in defunctzombie/node-url@e5b6f59

However, since this commit brings the url module in parity with node 0.12, it is very unlikely that there is currently frontend code out there which relies on such an old implementation of the url module. It is more likely that we actually fix code because developers assume a more recent implementation of the url module.

We should also switch all dependencies to the caret operator ^ to exclude breaking changes from 0.x modules.

@sokra @TheLarkInn @bebraw @SpaceK33z

Doing a fresh npm install this morning :

npm ERR! No compatible version found: node-libs-browser@^0.6.0
npm ERR! Valid install targets:
npm ERR! 1.0.0, 0.5.3, 0.5.2, 0.5.1, 0.5.0, 0.4.3, 0.4.2, 0.4.1, 0.4.0, 0.3.1, 0.3.0, 0.2.1, 0.2.0, 0.1.2, 0.1.1, 0.1.0

This is breaking npm install

Did the new 0.6.0 get pushed to npm ? Who is referencing it ? (most likely babel)

What is holding back adding an fs polyfill? I've seen many implementations for browser fs polyfills for node:

• https://github.com/jvilk/BrowserFS
• https://github.com/matthewp/fs
• https://github.com/mafintosh/browserify-fs

Seems possible. Any reasons why this hasnt been done yet? I can PR for this.

Refactor to a better drectory structure:

lib
  core - all libs
  mock - mocks of all libs
  util - shared stuff
  e5util - shared stuff without shims
test
  tests - shared test code for all environments
  environments - environments to run tests in with references to ../tests
    node
    browserify
    webpack

Confused as to the difference between this library

and

https://github.com/webpack/node-loader

Please let me know if the difference is documented somewhere, thank you

Version 0.5.3 depends on version 3.2.6 of crypto-browserify. That specific crypto-browserify version contains an error which causes trouble in my current project when processing its source with babel 6.

Would you mind updating to a crypto-browserify version >= 3.2.6 and release a new version to the npm repository?

I've collected the gap between Node.js core lib and webpack/browserify's shim lib.

Latest results is in following repository.

• azu/node-browser-shim-gap: The gap issue between Node.js and Browser shims..

Env

• Node.js 10.0.0
• webpack 4.6.0

Gap list

Tests

Also, I've written the test for these new methods/properties.

• node-browser-shim-gap/test.js at master · azu/node-browser-shim-gap

Node.js 10 pass the tests, but the code that is bundled by webpack is failed.

• webpack 4.6.0: https://travis-ci.org/azu/node-browser-shim-gap/jobs/373433188

v2.0.0 has not been tagged in git

It seems like there is no activity in

• defunctzombie/node-url#37
• webpack/webpack#5372

And i propose to replace node-url with

• jsdom/whatwg-url (but #102)
• or unshiftio/url-parse

I see this is still in the docs for webpack. How should we polyfill nodejs apis in the future? @sokra

@dominictarr introduced with browserify/crypto-browserify@9284566 a change which triggers a critical dependency warning due to a dynamic require.

What should we do @sokra? ^^

I'm trying to use this with react-native, but with additional shims for fs, dgram, dns.js and net. Right now I'm using a fork of this repo (and a fork of webpack because peerDependencies doesn't like git urls), but I thought maybe you had a better idea.

Missing http://nodejs.org/api/stream.html#stream_class_stream_transform

This means that I need to include readable-stream for webpack to work, which is okay I guess, as I already include that for node 0.8 anyway.

Not sure if this is the right place to post this issue.
According to the webpack docs global is polyfilled by default but it turns out to be undefined in my build.
Am I missing something?