-
Notifications
You must be signed in to change notification settings - Fork 117
node support #7
Comments
I would support that line of thinking if the new thing is practically and
|
+1 |
yeah i'm thinking only using ES6/WHATWG standards. do stuff like |
also, i'm not sure how to do node support for any new package manager without actually forking node. i wonder how they're going to implement es6 modules. |
Personally I would ignore es6 modules but I guess this is gonna get into
|
meh i don't think cjs -> es6 modules is a big deal (or vice versa for backwards compatibility). i'm just hoping people stop using RJS and creating UMD wrappers. |
👍 |
wouldn't that be a trio then? :P node will have to change the way packages are stored anyway because of long path issues on windows, so maybe this is a chance for global consensus on package path resolution nodejs/node-v0.x-archive#6960 |
Actually this was my original goal :-P. Node support can be done with require rewriting and symlinking. But it does require a lot of upfront work in the installer to walk and rewrite requires. |
👍 |
I would really love to use duo as an alternative to npm! I think it is also going to make duo a lot more appealing for library developers. I think you can get away without require rewriting and symlinking actually. I did it once with project called teleport. Since node lookup is basically based on looking into |
@matthewmueller on your request (in IRC) I made an example repo illustrating how node support can be implemented: https://github.com/Gozala/duo-node/tree/master/app You can also run If you look at the imports in the main.js there are two: var foo = require("gozala/foo")
var bar = require("gozala/[email protected]") On first require of
Note: Second line means see if In this case last lookup will succeed and load ./node_modules/gozala/foo/index.js. Which is great since dou can simply download modules form master branch of Second import of Things do get slightly tricky for the nested dependencies like in case of ./node_modules/gozala/[email protected]/index.js which depends on
Notice the pattern ? It basically walks the tree up to system root looking for desired modules under In nutshell due can stick to it's flat directory structure for dependencies and node will carry on with it's recursive lookup until app level dependencies are reached. This has following advantages over the current standard:
Note that in nutshell what due will need to do is treat In terms of tradeoffs due would have to adjust syntax slightly (as node will choke on |
As I already pointed out earlier sometime in the past I did a prototype of a tool that did something very similar. Although it tried to stay open and independent of github or other service and just supported URLs:
I'd be happy to help out with adding a node support as I really think something better than npm should come along & duo is on a right track. |
Oh and if we do end up implementing this we can then make duo use doe for it's dependency management and avoid |
For such “Node support” it might also be useful to leave Node's |
why? |
Otherwise you won't be able to call Node's |
The vastly better solution to that problem is to include a "no conflict" mode. (like jQuery does) I'm thinking a global DUO var will be unavoidable (albeit very helpful) as time goes on. |
Nope, that “no conflict” mode should be the only available mode. (Unless someone might actually have a reason to replace Node's |
@Mithgol that's the idea. |
I'm not sure if this discussion went completely sideways, but all I was describing works in node as is. All node would have to do is place installed files as described to be compatible with node. So I don't really support or like idea of changing require or coming up with some alternative. |
@Gozala +1 If we can't support node with what we already have, it's probably best suited for another project. Keep in mind this is a front-end package manager which means it will hopefully also be used outside of the node.js world. I don't want to couple Duo to the decisions that Node.js made. I think it's possible to get Node working and while changing the recursive directory structure to a flat directory structure. In fact, I think @Gozala was able to get this working in https://github.com/Gozala/duo-node. |
Ah, I understand the concept of @Gozala's demo now. It's not necessary to rename Duo's |
I'd just like to put it out there that it'd be nice if we could do away with
npm(1)
entirely (in the nicest way possible, it'd be good to have some healthy competition in this area).The text was updated successfully, but these errors were encountered: