Comments (18)
- 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/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.
Related Issues (20)
- Can't resolve 'fs' HOT 1
- resolve updates HOT 3
- add tests for pathFilter, packageFilter
- Use resolve 1.1.6 HOT 2
- alt-browser fallback to "browser" for browserification of dependencies? HOT 4
- global leak error detected in mocha HOT 1
- Feature request: option to intercept all disk I/O HOT 1
- Readme should be more accurate HOT 1
- Resolve fails for requires without file extension HOT 2
- No support for npm module name with "scope" yet? HOT 3
- node-resolve 1.1.7 HOT 1
- AssertionError: no line 0 (line numbers start from 1) while parsing file node_modules\browser-resolve\empty.js HOT 7
- Feature Request: Resolve Modules HOT 8
- Button on IE not working - works on all other browser
- Resolved files do not respect the `extensions` option HOT 6
- "resolve.mainFields"-like support HOT 1
- Update resolve dependency to 1.12.0 HOT 19
- "Error: Cannot find module" output should include filename
- Maintenance HOT 4
- 'process is not defined' when using process as a global HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from browser-resolve.