Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Duo – a next-generation package manager for the front end

duojs.org

Post reply on HN
Print view View original

41–50 of 103 posts

Re: Show HN: Duo – a next-generation package manager for the front end

#41

Post by wycats »

anthonyshort wrote: post #38
wycats wrote: post #37

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?

You'd use a component.json to lock it down for an app. The inline versioning is really just a way to quickly write code and get something up and running. Manifests are just a pain when you're just getting started with a project or a small script. If a component.json is present, it'll use that to get the versions and you just require('emberjs/ember-component')

Ah. I would probably clarify the language to make it clear that having a manifest approach is the intended approach for real-world apps, but that it can be left out when playing around.

Re: Show HN: Duo – a next-generation package manager for the front end

#42

Post by tonyhb »

TheHydroImpulse wrote: post #17
tjholowaychuk wrote: post #14

Earlier quoted context omitted.

I used to think this too, but the more I use Go the more I enjoy not needing to maintain a silly manifest

Then when you need to pin down versions and such, it's a massive pain (in terms of not being able to have a manifest file in Go's native case).

Pote's GVP/GPM works really well here. It's such a small system to learn and use, but does everything you could ever need when versioning godeps:

https://github.com/pote/gpm && https://github.com/pote/gvp

Re: Show HN: Duo – a next-generation package manager for the front end

#43

Post by wycats »

matthewmueller wrote: post #40
wycats wrote: post #37

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?

The manifest is optional, so for big projects I would probably recommend using a manifest to keep all your versioning in one place. 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.

I personally haven't had much trouble with:

  npm install foo --save-dev
When you go beyond a single developer playing around, having a quick, well-known place to look to learn what dependencies are being used is very useful.

Re: Show HN: Duo – a next-generation package manager for the front end

#44

Post by tomdale »

One question I always ask when looking at a package manager is, "Will this help me have reproducible builds?" (http://martinfowler.com/bliki/ReproducibleBuild.html)

I've worked on enough large projects that relied on prayer and optimism instead determinism when resolving dependencies, and eventually you end up losing hours or days trying to get the app running on a new server or a new developer's box.

Not requiring a manifest is a bug, not a feature. If people can specify dependencies, and information about the version used is lost, then you can be sure that it will happen in practice. Code designed for "proofs of concept" has a funny way of making it into production.

As we know from studies of things like organ donation rates, even the smartest humans get tired or distracted and make bad decisions. The only guard we have against it is choosing sane defaults. (See Yehuda Katz' RailsConf keynote for some interesting insight into how this interacts with convention over configuration: http://www.confreaks.com/videos/3337-railsconf-keynote-10-ye...).

While the simplicity of DuoJS allows it to win the Pepsi Challenge against other options, where the first sip tastes very sweet, I would never again willingly choose a dependency manager that makes reproducibility anything other than mandatory.

Re: Show HN: Duo – a next-generation package manager for the front end

#45

Post by bakareika »

anthonyshort wrote: post #30
tjsix wrote: post #29

Maybe it's just me but having no manifest makes using this tool quite painful. It has taken me 10 mins just to figure out how to structure the require()'s so that it doesn't error out, and that's with only requiring two packages. For example I created a quick index.js file and required angular and restangular. It immediately errored out because the angular.js repo doesn't use semver on it's master branch. Ok fine, sw…

index.js as the entry point for a module is pretty standard with projects built around Component and npm. It's bower and the lack of the standard there that creates the issue.

As an author of a (small) number of npm+bower packages I must admit that nope, that's not "standard" in any meaningful way.

Re: Show HN: Duo – a next-generation package manager for the front end

#46

Post by neilellis »

nawitus wrote: post #33
michaelmior wrote: post #21

Earlier quoted context omitted.

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.

Duo.js could implement duo_require for Node.js. Every "Duo.js Node.js" app would need to be bootstrapped with Node.js require, though.

It would be beautiful to have such a simple and open package manager for node. Git FTW :-)

Re: Show HN: Duo – a next-generation package manager for the front end

#47

Post by TheHydroImpulse »

tomdale wrote: post #44

One question I always ask when looking at a package manager is, "Will this help me have reproducible builds?" ( http://martinfowler.com/bliki/ReproducibleBuild.html ) I've worked on enough large projects that relied on prayer and optimism instead determinism when resolving dependencies, and eventually you end up losing hours or days trying to get the app running on a new server or a new developer's box. Not requiring…

https://github.com/duojs/duo/issues/220

Re: Show HN: Duo – a next-generation package manager for the front end

#48

Post by TheHydroImpulse »

wycats wrote: post #37

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?

People mentioned the manifest file, but I went one step further to try and get duo to adopt a lock file: https://github.com/duojs/duo/issues/220

Re: Show HN: Duo – a next-generation package manager for the front end

#49

Post by TheHydroImpulse »

bakareika wrote: post #45
anthonyshort wrote: post #30

Earlier quoted context omitted.

index.js as the entry point for a module is pretty standard with projects built around Component and npm. It's bower and the lack of the standard there that creates the issue.

As an author of a (small) number of npm+bower packages I must admit that nope, that's not "standard" in any meaningful way.

It's definitely standard in Node land and also Component(1). Bower, on the other hand, does not and thus is the culprit.

Re: Show HN: Duo – a next-generation package manager for the front end

#50

Post by nawitus »

anthonyshort wrote: post #36
nawitus wrote: post #34

Earlier quoted context omitted.

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.

But if you're at that point you probably have your own private git hosting somewhere too (or just private repos somewhere else). When there is support added for different remotes you could just require from there instead of Github. Point is, just use the git repos instead of needing that registry at all.

Yeah, that's working solution, when support for that is added. Assuming versioning works with these git urls.
Post reply on HN