This looks superb. Great work.
Show HN: Duo – a next-generation package manager for the front end
11–20 of 103 posts
Re: Show HN: Duo – a next-generation package manager for the front end
#12I think I'm missing something. I see how this would be great when it's build time but during development I don't want to have to keep running build commands each time I want to use a new package I'm development. Using Grunt and Bower may be a little time consuming up front but once things are set up its very easy to keep a separate Dev and prod environment in sync between different contributors. I only see the value…
You need to run a build script for Browserify as well, which IMO everyone who is using Bower/RequireJS should switch to.
Re: Show HN: Duo – a next-generation package manager for the front end
#13I think I'm missing something. I see how this would be great when it's build time but during development I don't want to have to keep running build commands each time I want to use a new package I'm development. Using Grunt and Bower may be a little time consuming up front but once things are set up its very easy to keep a separate Dev and prod environment in sync between different contributors. I only see the value…
I imagine it would possible to wire up a simple watcher in gulp/grunt that would do this automatically.
Re: Show HN: Duo – a next-generation package manager for the front end
#14Personally I think I'd much rather have my dependencies be explicit rather than inferred from what I require across my code base. The idea of a tool which supports both Bower and Component packages is quite nice though.
I used to think this too, but the more I use Go the more I enjoy not needing to maintain a silly manifest
Re: Show HN: Duo – a next-generation package manager for the front end
#15I'm not sure this actually improves the flow for me. I (like most sane devs), like to lock my deps to specific versions (or vendor them). Currently, it's just a matter of running:
npm install --save dep
With this, I either have to be satisfied with not locking down the version, or go lookup the current version manually before adding the reference to my code.
It also looks like upgrading a dep would mean changing every require.
Re: Show HN: Duo – a next-generation package manager for the front end
#16Personally I think I'd much rather have my dependencies be explicit rather than inferred from what I require across my code base. The idea of a tool which supports both Bower and Component packages is quite nice though.
Just to be clear, you can actually pin down the dependencies by creating a `component.json` manifest and adding the specific versions you want. You'd want to do this when publishing your own components, or when building a large app, but for quickly sketching out ideas you can just require them inline. Basically the manifest is optional, so you can choose when it makes sense to lock things down.
Re: Show HN: Duo – a next-generation package manager for the front end
#17Personally I think I'd much rather have my dependencies be explicit rather than inferred from what I require across my code base. The idea of a tool which supports both Bower and Component packages is quite nice though.
I used to think this too, but the more I use Go the more I enjoy not needing to maintain a silly manifest
Then when you need to pin down versions and such, it's a massive pain (in terms of not being able to have a manifest file in Go's native case).
Re: Show HN: Duo – a next-generation package manager for the front end
#18Personally I think I'd much rather have my dependencies be explicit rather than inferred from what I require across my code base. The idea of a tool which supports both Bower and Component packages is quite nice though.
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.
Re: Show HN: Duo – a next-generation package manager for the front end
#19The Go link should point to http://golang.org
Re: Show HN: Duo – a next-generation package manager for the front end
#20Personally I think I'd much rather have my dependencies be explicit rather than inferred from what I require across my code base. The idea of a tool which supports both Bower and Component packages is quite nice though.
Just to be clear, you can actually pin down the dependencies by creating a `component.json` manifest and adding the specific versions you want. You'd want to do this when publishing your own components, or when building a large app, but for quickly sketching out ideas you can just require them inline. Basically the manifest is optional, so you can choose when it makes sense to lock things down.
That's cool :) I assume the manifest can be auto-generated by examining the code? In that case, that makes me much more interested.