On: Show HN: Duo – a next-generation package manager f...

[wycats]

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?

[anthonyshort → wycats]

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

[wycats → anthonyshort]

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.

[matthewmueller → wycats]

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.

[wycats → matthewmueller]

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.

[TheHydroImpulse → wycats]

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