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

61–70 of 103 posts

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

#61

Post by munificent »

vkal wrote: post #5

So earlier this summer I learned how to use RequireJS + a smidgen of Grunt, then I felt the need to move towards Gulp and Browserify (which I've just recently started), and now I'm excited about Duo. It would be interesting for someone with more expertise to do a compare/contrast further down the line of all three. "...I show you how deep the rabbit hole goes" - Morpheus Also, does someone know how the Closure compil…

> I felt the need to move towards Gulp and Browserify

Dude, you're so behind the times. It's Yeoman and Bower now. Wait, Broccoli and Duo.

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

#62

Post by RoboTeddy »

ianstormtaylor wrote: post #59
RoboTeddy wrote: post #57

Earlier quoted context omitted.

The tool might have to recursively parse each file into an AST to find the `require` statements, and potentially apply various transforms (e.g. coffeescript). On large frontend codebases, these tasks can take an annoyingly long time. Hence, some tools cache (e.g. see browserify vs. watchify).

Yup, it will cache the files automatically and check mtime's so that only the changed files need to be reparsed for dependencies. It ends up being really fast to build once dependencies are installed.

Fantastic!

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

#63

Post by CMCDragonkai »

agumonkey wrote: post #54
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…

Talking about reproducible builds : is there something better than nix http://nixos.org/nix/ ? (honest question)

Nope. Nix is the best.

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

#64

Post by qwer »

compedit wrote: post #2

You can require dependencies and assets from the file system or straight from GitHub: Oh my. You've essentially killed Bower and NPM in one swoop then haven't you? An exciting time to be a web developer to say the least, this looks simply amazing.

npm already does this from any git repo. I have no idea why anyone would want to tie themselves to github only.

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

#65

Post by matthewmueller »

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…

Author here.

@tomdale We're on the same page. I've worked with many large JS codebases as well and consistency and repeatability are a must.

However, as with any tool, it's effectiveness comes from how you use it. There are so many NPM modules that use "*" in their manifests. That's not very robust. Having a manifest isn't a solution, it's how you use the manifest.

In Duo you can pin down any dependency right in the file via require('some/repo@tag'), which is the same as having a manifest with a pinned version.

With that being said, I'm open to any and all contributions or ideas on how to make Duo more consistent and repeatable. I love what Docker does for it's image builds and I think if we could get that kind of robustness going on the frontend, we would all benefit.

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

#66

Post by skeoh »

TheHydroImpulse wrote: post #49
bakareika wrote: post #45

Earlier quoted context omitted.

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.

index.js is only 'standard' in node insofar as it is the fallback entry point if a package.json file is not found or does not specify a 'main' file.

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

#67

Post by munificent »

matthewmueller wrote: post #65
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…

Author here. @tomdale We're on the same page. I've worked with many large JS codebases as well and consistency and repeatability are a must. However, as with any tool, it's effectiveness comes from how you use it. There are so many NPM modules that use "*" in their manifests. That's not very robust. Having a manifest isn't a solution, it's how you use the manifest. In Duo you can pin down any dependency right in the…

> In Duo you can pin down any dependency right in the file via require('some/repo@tag'), which is the same as having a manifest with a pinned version.

That will do nasty things for your ecosystem if people start doing that in libraries. You'll end up with version lock on shared dependencies:

    - My app depends on foo and bar.
    - foo and bar both depend on baz.
    - They both specify different tags.
Now your solver has a sad, and your user has a sad.

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

#68

Post by mattfenwick »

munificent wrote: post #67
matthewmueller wrote: post #65

Earlier quoted context omitted.

Author here. @tomdale We're on the same page. I've worked with many large JS codebases as well and consistency and repeatability are a must. However, as with any tool, it's effectiveness comes from how you use it. There are so many NPM modules that use "*" in their manifests. That's not very robust. Having a manifest isn't a solution, it's how you use the manifest. In Duo you can pin down any dependency right in the…

> In Duo you can pin down any dependency right in the file via require('some/repo@tag'), which is the same as having a manifest with a pinned version. That will do nasty things for your ecosystem if people start doing that in libraries. You'll end up with version lock on shared dependencies: - My app depends on foo and bar. - foo and bar both depend on baz. - They both specify different tags. Now your solver has a sa…

Sorry, I think I'm missing something because I don't see the problem -- why can't foo and bar just use different versions of baz? Is it not possible to do that?

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

#69

Post by aymericbeaumet »

Is Duo smart enough to remember when it finds a library requirement with a specific tag? So that it is not necessary to indicate the tag on the other places where this same library is required.

If so, manifests could be written in a very neat way. See: https://gist.github.com/aymericbeaumet/22c3a9deba54549821e3

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

#70

Post by Gigablah »

munificent wrote: post #61
vkal wrote: post #5

So earlier this summer I learned how to use RequireJS + a smidgen of Grunt, then I felt the need to move towards Gulp and Browserify (which I've just recently started), and now I'm excited about Duo. It would be interesting for someone with more expertise to do a compare/contrast further down the line of all three. "...I show you how deep the rabbit hole goes" - Morpheus Also, does someone know how the Closure compil…

> I felt the need to move towards Gulp and Browserify Dude, you're so behind the times. It's Yeoman and Bower now. Wait, Broccoli and Duo.

Yeoman isn't a build tool though, it just generates the application skeleton.
Post reply on HN