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

51–60 of 103 posts

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

#51

Post by lobster_johnson »

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.

It's only moderately common. Just took a look at a project of ours, and of 565 packages, only 261 (46%) had an index.js.

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

#52

Post by danielnaab »

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 achieved with an npm wrapper). Am I missing something?

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

#53

Post by TheHydroImpulse »

RoboTeddy wrote: post #39

Is it fast during development on large codebases? (e.g. by compiling incrementally)

The slow part is fetching dependencies. The "compiling" isn't compiling in the traditional compiled-language sense, where that would most likely take a significant amount of time.

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

#54

Post by agumonkey »

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)

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

#55

Post by [deleted] »

anthonyshort wrote: post #32
nawitus wrote: post #31

Is there support for symlinking for easy development? I mean the equivalent for 'npm link' or 'bower link'. Also, can you host your own "duo registry" (if the concept makes sense here). And if so, can you point to the private registry instead of using the public GitHub? Bower and npm supports these, and that's what I'm using currently.

For private packages, you'd just make the repo private on Github and make sure you have auth details in your .netrc file. So you don't really need your own "registry". There is talk about supporting more than just Github too.

[deleted]

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

#56

Post by chimeracoder »

michaelmior wrote: post #18
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

I keep meaning to spend some time playing with Go, but I haven't yet so I don't know how that feels. However, I wonder what it says that several dependency management tools have emerged for Go. https://github.com/mattn/gom https://github.com/nitrous-io/goop https://github.com/tools/godep

> 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. The last tool you mentioned, Godep, is one Go-specific approach at vendoring. It's also the one that I have anecdotally heard recommended, but this comes with absolutely zero personal experience and is solely hearsay.

But most projects don't even need to vendor - I've been writing Go as my primary language for almost 2 years both at work and for personal use, and I have never once needed godep. YMMV, obviously.

(Looking at tools that exist isn't meaningful in se, because people will try to build libraries to replicate pattern from other languages whether or not they apply. They will look for what they're familiar with, see that it's "missing", and then decide to write one, rather than questioning whether that idiom is actually appropriate for this new language.)

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

#57

Post by RoboTeddy »

TheHydroImpulse wrote: post #53
RoboTeddy wrote: post #39

Is it fast during development on large codebases? (e.g. by compiling incrementally)

The slow part is fetching dependencies. The "compiling" isn't compiling in the traditional compiled-language sense, where that would most likely take a significant amount of time.

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

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

#58

Post by michaelmior »

chimeracoder wrote: post #56
michaelmior wrote: post #18

Earlier quoted context omitted.

I keep meaning to spend some time playing with Go, but I haven't yet so I don't know how that feels. However, I wonder what it says that several dependency management tools have emerged for Go. https://github.com/mattn/gom https://github.com/nitrous-io/goop https://github.com/tools/godep

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

Fair enough that the existence of tools isn't really indicative of anything. Although at least the three I mentioned have a few hundred stars on GH which suggests some people are actually using them.

Anyway, thanks for sharing your experience! Your comment suggests to mean that you haven't had the need to fix the versions of any of your dependencies. Is that really true? I would find that quite surprising given that you've been coding in Go for a couple years.

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

#59

Post by ianstormtaylor »

RoboTeddy wrote: post #57
TheHydroImpulse wrote: post #53

Earlier quoted context omitted.

The slow part is fetching dependencies. The "compiling" isn't compiling in the traditional compiled-language sense, where that would most likely take a significant amount of time.

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.

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

#60

Post by munificent »

chimeracoder wrote: post #56
michaelmior wrote: post #18

Earlier quoted context omitted.

I keep meaning to spend some time playing with Go, but I haven't yet so I don't know how that feels. However, I wonder what it says that several dependency management tools have emerged for Go. https://github.com/mattn/gom https://github.com/nitrous-io/goop https://github.com/tools/godep

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

Post reply on HN