separate out assert and util about node-browser-builtins

[AndreasMadsen]

You will have to include the shims manually, to have a shared thing this way will just add to the maintains. But why would you want pull these out, there are almost just copy and paste. The modules as dependencies we have are generally hard to implement and except for the API they have nothing in common with the nodecore source. If anything the timers module should be pull out, since its an odd module too.

[defunctzombie]

Because modules should be self contained and live on npm :)

I actually removed the shims stuff per some discussions we are having to drop legacy support in favor of just recommending the use of polyfills.

[defunctzombie]

Have this working without shims and updated to latest node.js code

https://github.com/defunctzombie/node-util

The idea is that we can test them in isolation and they can be depended on without breaking if node versions change.

[AndreasMadsen]

Because modules should be self contained and live on npm :)

Well I agree. I'm just scared about the maintains when I upgrade the node version, with separated modules this will mean I/we have to supply pull requests to individual repositories instead of just one. This process is usually a lot longer and the complexity in the interdependent modules will also be higher.

[defunctzombie]

It sounds like you are making the argument that modules should live on npm except when you have to update modules :)

I think maintaining it will not be as bad as it seems and others can benefit from picking the modules they want for their projects.

If we agree that we don't care about shimming for legacy automatically then many things become way way simpler.

[AndreasMadsen]

If we agree that we don't care about shimming for legacy automatically then many things become way way simpler.

If that's the case then I will surly support this idea as the total maintains load will be much less than it is today.

It sounds like you are making the argument that modules should live on npm except when you have to update modules :)

As a general rule I will have to think long and hard about that, as it is hard to analyze one self. Especially in this case, since I like to think that I put load upon myself before others.

[AndreasMadsen]

Idea supported!

It sounds like you are making the argument that modules should live on npm except when you have to update modules :)

This one was hard. First of all I don't want to believe it. To believe that one puts loads upon one self rather than others is one thing, if its actually the case is completely different and almost impossible to reason about, as its very rare to get loud response from friends and enemies. I think this is especially the case when you are as young as me, you tend to think the entire world is against you. To separate my believes and reality in this case is definitely something I will have to focus on next year.

What I do know, is that it was 48+ hours process to get from 1.0.0 to 2.0.0 (the node version bump) and I don't see it become any different even for a simple node patch. That's a huge maintenance load (and very boring too) and the fact the browserify-buffer implementation was incomplete (both in feature and legacy support) and was used by different core modules was quite a pain.

As there are almost no maintenance (just copy&past and fix timers, buffer, process references and a IE11 shim) I will of of course support this.