Earlier quoted context omitted.
> Do you vendor [transitive dependencies] too? Yes. Here's an example: https://github.com/soundcloud/roshi
That sounds like a nightmare to maintain. :(
It's trivial.
Show HN: Duo – a next-generation package manager for the front end
101–103 of 103 posts
Re: Show HN: Duo – a next-generation package manager for the front end
#102Earlier quoted context omitted.
"Doctor, it hurts when I do this." What you're describing is an inappropriate intimacy antipattern.
Because people keep pinging me on twitter about this, I feel like I ought to explain a bit more. What's going on in the pattern described is that you're getting a `BazWidget1` object from the `foo` module. Then, you're passing that object you got from `foo` into `bar`, which passes it to `Baz2Flummox(BazWidget2 widget)`. Why are you flummoxing widgets that you don't know the origin of? What kind of program needs to m…
> clearly defined functions that take arguments and return values?
Sure, but what are the types of those arguments and return values?
If you call what I describe an anti-pattern, you're basically saying that packages can only interact using primitive types defined in the language. You can reuse code, but not data structures.
I think that's too much of a limitation. I want to reuse code that defines matrices, and vectors, and interesting collections, and business model objects like mailing addresses and currencies. I want to make games that use a mesh type defined in one package and pass it to a collision engine in another.
Saying "you can't use any user-defined type in any public API" is an incredibly harsh limitation, and what do you get for that in return? The ability to bloat your application with multiple versions of the same library?
Re: Show HN: Duo – a next-generation package manager for the front end
#103Just released a new library so Sass users can now use Duo.js with duo-sass (https://github.com/stephenway/duo-sass). Check it out!