allow versions like `require('express@4')`

[jonathanong]

:D

[dougwilson]

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]

Dude I think we could also patch node to not used nested dependencies!

[jonathanong]

Nevermind, too many obstacles haha

[dougwilson]

Nevermind, too many obstacles haha

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]

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

[dougwilson]

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

[reqshark]

first pass

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.

[heapwolf]

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]

tricky, ya eval() is basically script twerking. node-normalize is much better

[jonathanong]

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

[heapwolf]

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:

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

Paolo Fragomeni
Founder, Here is How
http://hereishow.to

github.com/hij1nx
twitter.com/hij1nx

[jonathanong]

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

[reqshark]

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