extract node buildins

[sokra]

hey @shtylman

is there any chance we can extract all replacements for node.js buildin node modules into a separate module (i. e. "node-browser-core"), which exports them the way you filled them into core:

{
  fs: "/path/to/node_modules/node-browser-core/buildin/fs.js",
  http: "/path/to/node_modules/node-browser-core/node_modules/http-browserify/index.js",
  /* ... */
}

This module would be a good place for tests too...

I would like to use it for webpack. I think it's a good idea to have only one place for browser node.js libs, which can be used by every bundler...

@substack @Raynos

[sokra]

• https://github.com/shtylman/node-browser-resolve/tree/master/builtin
• https://github.com/shtylman/node-script/tree/master/shims
• https://github.com/webpack/webpack/tree/master/buildin/web_modules
• https://github.com/michaelficarra/commonjs-everywhere/tree/master/core
• and serveral modules for single node buildins

[defunctzombie]

Script is gonna get deprecated in favor of browserify.

Some of these things already exist as -browserify module and I suppose we can do that for the rest.

Anyone think this is a bad idea? On Feb 22, 2013 6:36 PM, "Tobias Koppers" notifications@github.com wrote:

• https://github.com/shtylman/node-browser-resolve/tree/master/builtin
• https://github.com/shtylman/node-script/tree/master/shims
• https://github.com/webpack/webpack/tree/master/buildin/web_modules

• and serveral modules for single node buildins

  — Reply to this email directly or view it on GitHubhttps://github.com/shtylman/node-browser-resolve/issues/6#issuecomment-13979627.

[Raynos]

I think https://github.com/shtylman/node-browser-resolve/tree/master/builtin is the place where the builtins should live.

At least I feel that @shtylman and @substack are deprecating the location of them.

I do think we should move more builtins into seperate modules though instead of one big one

[sokra]

I meant moving all of them into one module. Maybe even moving the xxx-browserify modules into that one module (but this is optional).

If they are in node-browser-resolve it's kind of hacky to use them with a other or without a resolving algorithm.

[sokra]

So I merged your buildin modules with mine buildin modules and fixed some stuff. I extracted all these modules into an separate package node-libs-browser and let webpack use it.

I added some test, but they doesn't pass all yet.

If you choose to use the package for browserify too, it would be great to merge our efforts. You can get write access to the repo. :+1:

Found another bundler which has references to the node buildin modules @michaelficarra

[michaelficarra]

@sokra: I just include node itself as a git submodule and symlink the pure JS lib files in commonjs-everywhere.

[defunctzombie]

I will take a look. We will not be including node itself as that is incorrect and doesn't allow us to make the builtins work on browsers. On Feb 25, 2013 5:43 AM, "Tobias Koppers" notifications@github.com wrote:

So I merged your buildin modules with mine buildin modules and fixed some stuff. I extracted all these modules into an separate package node-libs-browser https://github.com/webpack/node-libs-browser and let webpack use it.

I added some test, but they doesn't pass all yet.

If you choose to use the package for browserify too, it would be great to merge our efforts. You can get write access to the repo. [image: :+1:]

Found another bundler which has references to the node buildin modules @michaelficarra https://github.com/michaelficarra

— Reply to this email directly or view it on GitHubhttps://github.com/shtylman/node-browser-resolve/issues/6#issuecomment-14035074.

[michaelficarra]

@shtylman: For most of node, it is just a pure JS lib. These all work in the browser just fine:

• assert
• console
• domain
• events
• freelist
• path
• punycode
• readline
• stream
• string_decoder
• sys
• url
• util

[defunctzombie]

They don't work in as many browsers as we want to support. We also was to manage their sizes better. On Feb 25, 2013 9:41 AM, "Michael Ficarra" notifications@github.com wrote:

@shtylman https://github.com/shtylman: For most of node, it is just a pure JS lib. These all work in the browser just fine:

• assert.js
• console.js
• domain.js
• events.js
• freelist.js
• path.js
• punycode.js
• readline.js
• stream.js
• string_decoder.js
• sys.js
• url.js

• util.js

  — Reply to this email directly or view it on GitHubhttps://github.com/shtylman/node-browser-resolve/issues/6#issuecomment-14045311.

[sokra]

@michaelficarra They may work in chrome with v8 but should have problems with other browsers, especially older browsers.

[michaelficarra]

Ah, makes sense.

[sokra]

yeah, and therefore my approach of creating a common package for node.js buildin libs for in browser use. The most code is similar to the node.js core code, but in some pieces it differs from it. I. e. it doesn't use Object.keys directly but uses a shim if it is not availible...

[defunctzombie]

@sokra (utils.inherits should be separated out as well). I like the approach of making the core libs smaller via partial util usage (I hate util)

Some more feedback: I would really like it if we found a way to actually test the modules via testling I would be happier about making changes to them.

I am also not sure I like the whole directory structure organization. I kinda want something simpler file wise and maybe provide the meta information you want by listing it manually versus via folders. It makes it harder to hunt down the things I want when they are all over the place in folders.

[sokra]

Feel free to propose a better structure... Also a better testablility would be great. I'm not really in to that testling thing, but sounds great. (A bit expensive?)

yes the directory structure need to be updated... My goal was to provide full featured libs and mock of the libs and let the developer opt-out to the mock version. (Because some modules depend on node libs, but not really use them. So the developer con use to use only a mock versions to save space). I'll create a issue.

The initial focus was to convice you for a shared package...

[defunctzombie]

On Feb 25, 2013, at 10:30 AM, Tobias Koppers notifications@github.com wrote:

Feel free to propose a better structure... Also a better testablility would be great. I'm not really in to that testling thing, but sounds great. (A bit expensive?)

Free for open source.

yes the directory structure need to be updated... My goal was to provide full featured libs and mock of the libs and let the developer opt-out to the mock version. (Because some modules depend on node libs, but not really use them. So the developer con use to use only a mock versions to save space). I'll create a issue.

We can still do that, but just not using the directory structure. I would flatten the structure as the first thing and expose things in a simpler manner :)

The initial focus was to convice you for a shared package...

Fair enough ;)

— Reply to this email directly or view it on GitHub.

[defunctzombie]

browser version of core libs are no longer part of this module. Bundle tools should include them however they see fit.

[Raynos]

@shtylman where were the browser versions of core libs moved to?

[defunctzombie]

Nowhere yet. But they should either be in browserify itself (or the various modules like http-browserify). And other bundlers can choose to use whatever they want themselves. This makes more sense since it could be bundler specific and/or up for debate about how best to provide which core shims.