Also, can you host your own "duo registry" (if the concept makes sense here). And if so, can you point to the private registry instead of using the public GitHub?
Bower and npm supports these, and that's what I'm using currently.
31–40 of 103 posts
Also, can you host your own "duo registry" (if the concept makes sense here). And if so, can you point to the private registry instead of using the public GitHub?
Bower and npm supports these, and that's what I'm using currently.
Is there support for symlinking for easy development? I mean the equivalent for 'npm link' or 'bower link'. Also, can you host your own "duo registry" (if the concept makes sense here). And if so, can you point to the private registry instead of using the public GitHub? Bower and npm supports these, and that's what I'm using currently.
I love simple things, this gets my +1, look forward to learning more. I can't see why this is browser only, am I missing something?
I'd imagine doing this for node.js would require modifications to node itself since the behaviour of require would need to change. On second thought, I suppose you could just rename packages and mess with their path in node_modules to make things work. But that would mean moving out of the npm ecosystem which seems rather bold.
Is there support for symlinking for easy development? I mean the equivalent for 'npm link' or 'bower link'. Also, can you host your own "duo registry" (if the concept makes sense here). And if so, can you point to the private registry instead of using the public GitHub? Bower and npm supports these, and that's what I'm using currently.
For private packages, you'd just make the repo private on Github and make sure you have auth details in your .netrc file. So you don't really need your own "registry". There is talk about supporting more than just Github too.
Does this have any more to offer other than deducting what to download&install from the dependency tree? Because if that's "all", it would be easily added to e.g. webpack, I suppose. Is it really worth making yet another dependency and build tool just for that one feature? If you build on top of webpack, you get a lot of stuff for free, like speedy and dependable file watching, hot-reloading development servers, support for nearly any imagineable frontend language, and a remarkably decent extensible architecture. All this has to be made again for Duo.
Both dependency management and frontend building are highly complex tasks. I'm not saying that therefore it couldn't be done better, but I do honestly, without judging, wonder whether the authors seriously considered existing solutions and ran into impossible problems, or whether this is just the Not Invented Here syndrome at work.
Earlier quoted context omitted.
For private packages, you'd just make the repo private on Github and make sure you have auth details in your .netrc file. So you don't really need your own "registry". There is talk about supporting more than just Github too.
That's a rather centralized solution. There are many companies who host their own npm/bower registries, and they won't move to Duo.js until that's possible.
Point is, just use the git repos instead of needing that registry at all.
require("emberjs/ember-component@^1.6.1")
Doesn't this mean that to update an Ember package, I have to change every file that references that package? That would mean having to touch the JS file for every component in your project to bump the version.Am I missing something?
It sounds like this means that if I wanted to use a specific version of Ember, I would have something like the following line in many files: require("emberjs/ember-component@^1.6.1") Doesn't this mean that to update an Ember package, I have to change every file that references that package? That would mean having to touch the JS file for every component in your project to bump the version. Am I missing something?
If a component.json is present, it'll use that to get the versions and you just require('emberjs/ember-component')
It sounds like this means that if I wanted to use a specific version of Ember, I would have something like the following line in many files: require("emberjs/ember-component@^1.6.1") Doesn't this mean that to update an Ember package, I have to change every file that references that package? That would mean having to touch the JS file for every component in your project to bump the version. Am I missing something?
Duo falls back to the manifest if it cannot resolve the path on it's own.
For proof of concepts and hacks though, adding a manifest is a waste of everyone's time.