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

81–90 of 103 posts

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

#81

Post by andreaf »

I am a little confused about how Duo actually transforms dependencies into JS values. When I write, say,

var uid = require('matthewmueller/uid');

as in the home page example, what gets bound to the uid identifier?

The point is that a package manager does not only need to fetch dependencies, but also to specify relations between modules. This is why, for instance, Bower only does half the story (fetching) and it has to be coupled with a tool like Require.js to actually provide modules.

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

#82

Post by andreaf »

andreaf wrote: post #81

I am a little confused about how Duo actually transforms dependencies into JS values. When I write, say, var uid = require('matthewmueller/uid'); as in the home page example, what gets bound to the uid identifier? The point is that a package manager does not only need to fetch dependencies, but also to specify relations between modules. This is why, for instance, Bower only does half the story (fetching) and it has t…

For clarity, let me make a comparison with the JVM. On the JVM, when one requires a class in a package, it is up to a classloader to find it. The default classloader will look up the class code in a directory structure based on the package name. Where to locate this directory structure is decided based on environment variables, but usually it ends up to having multiple entry points, either on the filesystem or inside zipped files called JARs. A separate tool, like Maven on SBT, can help you fetch JARs from repositories. But what actually makes everything click is the fact that once you have fecthed the JAR, you know where to locate classes inside it based on their name.

In the frontend world there just isn't such a standardization on paths, and this is what makes it difficult to locate a module even when the Github repo for it has been downloaded.

How does Duo solve this issue?

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

#83

Post by aymericbeaumet »

anthonyshort wrote: post #74
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 :)

A one could indeed export its requires. However, my idea was was to stay close to the require caching system existing in Node.

As a personal taste, I by far prefer to configure my application in a JavaScript file rather than a JSON file. And I consider dependencies as a part of the configuration process. It agrees with the Duo philosophy which aims to simplify the building process from A to Z.

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

#84

Post by cel1ne »

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 tried a lot and use RequireJS + Gulp now (same Gulpfile on every project). Works for me, I don't see a compelling reason to change something.

My Gulpfile has 200 lines and does everything from asset-manifests to css minification, js-reloading etc.

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

#85

Post by mattfenwick »

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.

Please forgive my ignorance, but what is the problem with bundling n different versions of a library? Is it just that the bundle size increases? Or are there additional problems?

(That's not to say that the bundle size isn't important -- just that I would like to know if it's the only drawback)

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

#86

Post by dsr_ »

mattfenwick wrote: post #85
thethimble wrote: post #73

Earlier quoted context omitted.

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.

Please forgive my ignorance, but what is the problem with bundling n different versions of a library? Is it just that the bundle size increases? Or are there additional problems? (That's not to say that the bundle size isn't important -- just that I would like to know if it's the only drawback)

Foo calls Bar and Baz, Bar calls Qux:0.01 and Baz calls Qux:0.05. Your project is Rumba, which calls methods from Bar and Baz and also needs Qux:0.2, although it turns out that you can use anything from Qux:0.03 through 0.3 and you just specified it as Qux, unversioned.

Your coworker is having problems with Baz. How many collisions are in your brain right now when you think about Qux.GiveAnother ?

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

#88

Post by theefer »

People interested in Duo may also want to have a look at jspm.io. It solves a similar problem, but with a few differences which to me are advantages:

- Transparently supports modules from CommonJS, AMD, ES6 or globals.

- Enforce a manifest (config.js) that let you pin dependencies (incl. transitive dependencies) to exact versions. Unlike RequireJS config, jspm automatically manages that file for you.

- Support multiple package providers, e.g. NPM, on top of Github.

- Based on SystemJS, a polyfill for the upcoming standard System loader. This hopefully makes it future-proof.

- Does not require a compilation step: dependencies can be pulled dynamically from a CDN over SPDY. Alternatively they can be cached locally as well. A compilation step (jspm bundle) is still available.

- Works both in the context of Node and the browser.

We've been successfully using jspm and SystemJS in production at the Guardian. It's still early days, but the devs are very active and responsive.

This isn't meant to distract people away from taking a look at Duo and making up their own mind, but I noticed nobody mentioned jspm in this thread and thought people may want to look at both and compare.

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

#89

Post by munificent »

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?

Let's say your app my_app uses foo and bar. They both use baz. You give them each their own version of baz: foo gets baz 1.0 and bar gets baz 2.0.

Now, at runtime:

    my_app calls foo.giveMeAWidget()
    foo calls new baz.Widget() on its 1.0.0 version of baz
    my_app gets that back
    then it calls bar.doSomethingWithAWidget(widget) and passes it in
    bar calls baz.flummoxAWidget(widget) and passes the widget in
    baz.flummoxAWidget() starts doing stuff with the widget
The last step is bad. You have baz 2.0.0 code that assumes it has a baz 2.0.0 widget, but it's actually a 1.0.0 one. It could work, crash, or fail in some subtle way.

Note that this isn't statically detectable. It's based on how objects flow around in memory at runtime.

Now, in cases where you don't pass objects around like this, you'll avoid this problem. But it's really hard to tell when that's the case and when it isn't.

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

#90

Post by munificent »

sagichmal wrote: post #77
munificent wrote: post #60

Earlier quoted context omitted.

> 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

That sounds like a nightmare to maintain. :(
Post reply on HN