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

71–80 of 103 posts

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

#71

Post by steveklabnik »

mattfenwick wrote: post #68
munificent wrote: post #67

Earlier quoted context omitted.

> 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?

Depends on the language.

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

#72

Post by matthewmueller »

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…

you can require two different versions of the same library and it works just fine. uses a similar process as browserify.

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

#73

Post by thethimble »

mattfenwick wrote: post #68
munificent wrote: post #67

Earlier quoted context omitted.

> 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?

Sadly, this isn't really a solvable problem. On one extreme you force all transitive dependencies to use the same version. On the other extreme, you bundle n different versions of a library. Organizations such as Google have strict policies to enforce the former extreme - only one version of a library is allowed at a time. Unfortunately, this isn't possible for the OSS community where there's no enforceability.

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

#74

Post by anthonyshort »

aymericbeaumet wrote: post #69

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

You could also just export from each of the requires in that manifest.js file you have there.

Although there's no real benefit of doing that over using the manifest other than it's kinda cool :)

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

#75

Post by ianstormtaylor »

thethimble wrote: post #73
mattfenwick wrote: post #68

Earlier quoted context omitted.

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?

Sadly, this isn't really a solvable problem. On one extreme you force all transitive dependencies to use the same version. On the other extreme, you bundle n different versions of a library. Organizations such as Google have strict policies to enforce the former extreme - only one version of a library is allowed at a time. Unfortunately, this isn't possible for the OSS community where there's no enforceability.

With Duo you can actually have multiple versions of the same Javascript dependency. And then you can use the CLI to figure out what duplicates you have if you want to slim them down.

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

#76

Post by ianstormtaylor »

aymericbeaumet wrote: post #69

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

That is a pretty cool idea! I wouldn't have even thought to do that

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

#77

Post by sagichmal »

munificent wrote: post #60
chimeracoder wrote: post #56

Earlier quoted context omitted.

> However, I wonder what it says that several dependency management tools have emerged for Go. In the case of Go, it's more meaningful to note that most larger Go projects have been developed for quite some time without needing any of these tools. If you need specific versions, the standard, idiomatic Go approach is to vendor your dependencies. Google, for example, does not use any Go-specific tool for vendoring IIRC…

> If you need specific versions, Who doesn't need this? Do you really want different people on your team accidentally using different versions of dependencies? > the standard, idiomatic Go approach is to vendor your dependencies. How does that work with transitive dependencies? Do you vendor those too? > Google, for example, does not use any Go-specific tool for vendoring IIRC. How much third-party code does Google a…

    >  Do you vendor [transitive dependencies] too?
Yes. Here's an example: https://github.com/soundcloud/roshi

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

#78

Post by matthewmueller »

danielnaab wrote: post #52

npm supports git repositories as dependencies already (git://github.com/...), so that feature doesn't seem like much added value to me. And considering that any real project needs a manifest, the versioning syntax doesn't seem especially compelling. I'd like to be proven wrong, because this looks cool... but I don't see the value over npm and browserify other than some syntactical sugar (which could probably be achie…

don't remember the details, for simple repos it's fine, i think it's a dependency of dependency problem, that isaac's didn't want to support for some reason.

here's a rabbit hole of additional information: https://github.com/npm/npm/issues/3014

:-)

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

#79

Post by matthewmueller »

fiatjaf wrote: post #23

Does a simple `require('package')` without the slashes fetch the thing from NPM? Maybe it could. Maybe it could also work with `require('package@0.5.1')` and other sugars like this.

require('package') will look into the manifest to see if there's a remote path and version to use, otherwise it will be set as unresolved and ignored in the build.
Post reply on HN