alexgorbatchev / node-browser-builtins Goto Github PK

the name of this repo should be node-browserify-builtins?
NVM, just a suggestion, haha

querystring.format({ foo: ["1", "2"] })

has different outputs in node and these browser-builtins. In node it does ?foo=1&foo=2, in this module it does ?foo[]=1&foo[]=2

This module should be fixed to comply with node core.

@alexgorbatchev you seams to be a busy guy, you should consider adding another maintainer to this project. Maybe one from browserify.

When you require something like assert you get ALL 6kb of shims even though assert only uses a shim for Object.keys() which is only 270 bytes. People complain all the time about bundle sizes and I think breaking the shims up into separate files could help a lot with that complaint.

This error is caused by https://github.com/alexgorbatchev/node-browser-builtins/blob/master/builtin/util.js#L44

This should be https://github.com/joyent/node/blob/be940b45016380322430411b19a354867f0f9ef2/lib/util.js#L173

I got some weird problems with tape after upgrading browserify from 2.29.1 to 2.30.0 and I traced the problem down to the browser-builtins package.

When I switched from browser-builtins version ~2.0.1 back to ~1.0.1 in browserify 2.30.0 and 2.34.3 I don't get the errors.

I dissected the browser-builtins repo and found that the last working commit for me is c1bc56a, then there is one commit that won't work at all e08cda5 and the commit after that 5fa8c3f produces my error (I had to manually copy the _shims.js file from a later commit because it was required).

Running my browserifyed tape tests in Chrome with browser-builtins from commit 5fa8c3f and later results in each tape test running many times instead of just once.

In the console this error is shown a couple of times:

(node) warning: possible EventEmitter memory leak detected. 11 listeners added. Use emitter.setMaxListeners() to increase limit.
    EventEmitter.addListener

So I'm guessing that I have some problem with the EventEmitter implementation.

Unfortunately the diff on commit e08cda5 and 5fa8c3f is quite large and I haven't had time to look in to the details of the changes yet.

I raised an issue on browserify regarding this.

I also confirmed that swapping browser-builtins~1.0.7 back in fixes this issue.

CoffeeScript does a require("module") at some point, which is causing problems with browserify. But it turns out that in a lot of useful paths through the CoffeeScript module, the "module" module is not used.

Easy fix is to add an empty module "module".

@AndreasMadsen out build is failing all of a sudden... do you know if something broke from under us?

As a principal I believe that either you support a old browser or you don't, there should be no half solutions. It is way to complicated for those there use this project to care about browser support on a individual module or function level.

So since the big 2.0.0 bump we fully support IE8+. I made this decision because there was already some IE8 support and I didn't want more migration trouble for userland than they already where (caused by the node version bump).

Some time has now passed and pull-request #36 and issue #19 are good reasons to drop IE8 support. Since I'm quite distant from the browserify community I can't really make this decision.

/cc @alexgorbatchev @substack @Raynos @defunctzombie

https://github.com/alexgorbatchev/node-browser-builtins/blob/master/builtin/assert.js#L78

Do we really want assert.AssertionError constructor to be instance of Error constructor ?
I just tested in nodejs:

var assert = require('assert');
console.log(assert.AssertError instanceof Error); // outputs false

The latest version of browser-builtins, 1.0.3 doesn't have the patches that @juliangruber sent 2 weeks ago that add support for the "constants" module

Travis-CI with zuul now works and I have updated all the dependencies.

@alexgorbatchev if you would npm publish.

It would also be nice if you would npm owner add andreasmadsen so I can do it myself in the future.

The event module doesn't check for the presence of console, or the 'error' or 'trace' methods before using

The utils module doesn't check for the presence of console.

@alexgorbatchev please publish the new version

also I think you can close the other issues.

@alexgorbatchev as a last thing to get zuul up and running you will have to perform this step: https://github.com/defunctzombie/zuul/wiki/Travis-ci#5-final-step

remember to push to upstream.

At some point I tried to switch to only using external modules. But unfortunately the tests fails because they aren't as well tested as this setup.

However the end goal is still valid.

PS: I do very little browser stuff these days, so I doubt I will feel like doing this any time soon.

Currently process is resolved with "process": require.resolve('process/') but the process package has one entry point for Node and one for browser. By using require.resolve('process/') you get the Node entry point, which doesn't work for the browser. The same fix should be applied to process that is applied to os-browserify.

That is, this line:

"process": require.resolve('process/'),

Should be:

"process": path.resolve(require.resolve('process/'), '..', 'browser.js'),

I am pulling out the assert and util module into separate modules. How do we want to handle the _shims in this case since both of those modules seem to use them (in module and tests)?

It seems the index.js references an https local library, but there is none in the builtins directory.

I can't find events.js in builtin, is it in another repository?

Lets say I'm using the brfs transform and have the following code:

var fs = require('fs');

var go = module.exports = function () {
  var md = fs.readFileSync(__dirname + '/README.md');
  console.log(md);
};

Although the readFileSync call is replaced, the fs require still happens, which throws and thus crashes my client side init.

I have to do the following workaround (there are other ways), but none are ideal:

var fs;

try {
  fs = require('fs');
} catch (e) {}

var go = module.exports = function () {
  var md = fs.readFileSync(__dirname + '/README.md');
  console.log(md);
};

As I can see this was introduced a month ago. Could we please roll that back?