extract node buildins about browser-resolve HOT 18 CLOSED

• 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

from browser-resolve.

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" [email protected] 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//issues/6#issuecomment-13979627.

from browser-resolve.

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

from browser-resolve.

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.

from browser-resolve.

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. 👍

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

from browser-resolve.

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

from browser-resolve.

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" [email protected] 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: 👍]

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//issues/6#issuecomment-14035074.

from browser-resolve.

@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

from browser-resolve.

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" [email protected] 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//issues/6#issuecomment-14045311.

from browser-resolve.

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

from browser-resolve.

Ah, makes sense.

from browser-resolve.

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...

from browser-resolve.

@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.

from browser-resolve.

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...

from browser-resolve.

On Feb 25, 2013, at 10:30 AM, Tobias Koppers [email protected] 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.

from browser-resolve.

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

from browser-resolve.

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

from browser-resolve.

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.

from browser-resolve.