You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yes! I just saw you made this module. I love lib::xi, so I was thinking of making something like that for node.js now that there will be execSync. You beat me to it :P
Yea. Basically to me, you can have nested dependencies and have a reliable dependency tree, or not have them and have a flat tree where you can only have one version of any module, a. la. perl and the like. Personally I like the elegance and simplicity of the nested dependency tree, even on Windows :)
If you look at normalize docs, I basically do repositories/module/version, so you could have multiple versions of a package installed. Flat doesn't mean only single versions like bower
I know. The biggest problem is a file that does require('thing') and there are multiple versions of thing and no package.json file. That's basically the single thing about the whole thing that would not be backwards-compatible. Of course, if require took version numbers... ;)
reads script as string. parse out requires with dep settings, get rid of the setting @whatever from any of those requires, pushing such onto an array. then just call execFile('npm', ['install', name]) with those from such array concatted to name
second pass
use eval() like a boss with all the nice looking requires.
i think i've figured out a way to do this with a flat dep structure, but it might be slow since i'll be doing a lot of moving folders around and symlinking. biggest problem is that it won't be compatible with npm tools, so we'll have to create our own tools ourselves, like outdated and shrinkwrap.
i don't think we should use all the other normalize stuff for this because we need npm's support for C/C++ addons. i don't want to build that stuff into normalize. but people should still be able to install tarballs off github via require('component/emitter@1'), etc.
are you guys down to help? this isn't something i'm really interested in because i'm okay with how npm works right now (client-side stuff is much more terrible and complex), but i would use if it were production-ready.
on the other hand, we could wait for es6 modules in node... in two years...
A simple-upgrade-path-to-nothing is awesome. but introducing new tools to
get rid of old tools will just leave us with a lot of tools. Here's an
idea: what about npm install a-patched-node-version?
i think i've figured out a way to do this with a flat dep structure, but
it might be slow since i'll be doing a lot of moving folders around and
symlinking. biggest problem is that it won't be compatible with npm tools,
so we'll have to create our own tools ourselves, like outdated and
shrinkwrap.
i don't think we should use all the other normalize stuff for this because
we need npm's support for C/C++ addons. i don't want to build that stuff
into normalize.
are you guys down to help? this isn't something i'm really interested in
because i'm okay with how npm works right now (client-side stuff is
much more terrible and complex), but i would use if it were
production-ready.
on the other hand, we could wait for es6 modules in node... in two years...
—
Reply to this email directly or view it on GitHub #3 (comment).
yeah i was thinking about just forking node, but that's way too much maintenance for something i don't care enough about. a patched node makes sense as it would be much less maintenance. i was thinking of calling it nope.js for all the things the node team refuses to do
Activity
dougwilson commentedon Jun 21, 2014
Yes! I just saw you made this module. I love lib::xi, so I was thinking of making something like that for node.js now that there will be execSync. You beat me to it :P
jonathanong commentedon Jun 21, 2014
Dude I think we could also patch node to not used nested dependencies!
jonathanong commentedon Jun 22, 2014
Nevermind, too many obstacles haha
dougwilson commentedon Jun 22, 2014
Yea. Basically to me, you can have nested dependencies and have a reliable dependency tree, or not have them and have a flat tree where you can only have one version of any module, a. la. perl and the like. Personally I like the elegance and simplicity of the nested dependency tree, even on Windows :)
jonathanong commentedon Jun 22, 2014
If you look at normalize docs, I basically do
repositories/module/version, so you could have multiple versions of a package installed. Flat doesn't mean only single versions like bowerdougwilson commentedon Jun 22, 2014
I know. The biggest problem is a file that does
require('thing')and there are multiple versions ofthingand nopackage.jsonfile. That's basically the single thing about the whole thing that would not be backwards-compatible. Of course, ifrequiretook version numbers... ;)reqshark commentedon Jun 22, 2014
first pass
reads script as string. parse out requires with dep settings, get rid of the setting
@whateverfrom any of those requires, pushing such onto an array. then just callexecFile('npm', ['install', name])with those from such array concatted tonamesecond pass
use eval() like a boss with all the nice looking requires.
heapwolf commentedon Jun 22, 2014
That's tricky, which is why I ended up doing this -- https://github.com/normalize/node-normalize, which could do
require('express@4')pretty easily i think.reqshark commentedon Jun 22, 2014
tricky, ya
eval()is basically script twerking. node-normalize is much betterjonathanong commentedon Jun 22, 2014
i think i've figured out a way to do this with a flat dep structure, but it might be slow since i'll be doing a lot of moving folders around and symlinking. biggest problem is that it won't be compatible with npm tools, so we'll have to create our own tools ourselves, like
outdatedandshrinkwrap.i don't think we should use all the other normalize stuff for this because we need
npm's support for C/C++ addons. i don't want to build that stuff into normalize. but people should still be able to install tarballs off github viarequire('component/emitter@1'), etc.are you guys down to help? this isn't something i'm really interested in because i'm okay with how npm works right now (client-side stuff is much more terrible and complex), but i would use if it were production-ready.
on the other hand, we could wait for es6 modules in node... in two years...
heapwolf commentedon Jun 22, 2014
A simple-upgrade-path-to-nothing is awesome. but introducing new tools to
get rid of old tools will just leave us with a lot of tools. Here's an
idea: what about
npm install a-patched-node-version?On Sat, Jun 21, 2014 at 10:22 PM, Jonathan Ong notifications@github.com
wrote:
Paolo Fragomeni
Founder, Here is How
http://hereishow.to
github.com/hij1nx
twitter.com/hij1nx
jonathanong commentedon Jun 22, 2014
yeah i was thinking about just forking node, but that's way too much maintenance for something i don't care enough about. a patched node makes sense as it would be much less maintenance. i was thinking of calling it
nope.jsfor all the things the node team refuses to doreqshark commentedon Jun 22, 2014
hahahaha get the latest updates and nope.js patches from nopejs.org.
no don't patch node wtf are you saying, just use javascript. flat deps