combinatorials about depject HOT 6 OPEN

dude bro don't just slap an issue down like it's a graffitti on a bathroom stall, yo gotta write a poem or short story about why it should be

from depject.

"should be easy"

from depject.

Uhm, it's like simply showing up to a convention, I've already made my contribution here... where's the snack table?

But all right, give me the mic: I believe the proposed upgrade needs to work through each combination, starting at the top or bottom, not flatly combining all tha deps, so that if you have multiple layers, lyk dis:

combo = combine([a,c,b])
comboPlugin = combine([combo, x, y, z])
comboDelux = combine([comboPlugin, e, f, g])

then your deps will resolve according to the combinations; comboDelux will need the output of comboPlugin, which needs the output from combo. Or maybe it goes the other direction, idk, maybe it can go both ways...

from depject.

so, for this to work - combine would have to return an object with {gives, needs, create} on it. So then to start the app you'd just call combine([...]).create() and call it empty because you shouldn't have any needs left right? but if a combination of modules is missing a need when you call combine it would return an object with those needs expressed.

would it actually behave differently as long as the order is the same?

combine([a,b,c]) == combine([combine([combine([a]), b]), c]) == combine([a, combine([b, c])])

This would be the same behaviour if combine is just concat

from depject.

neat, but forcing an order is imho not desirable, in general, but specifically b/c that will make things break awfully if you require a bunch of a features, but don't know which order to concat them (at which point you've truly resurrected script tag madness, tyvm)

But I really must cease my conjectures, until further review, right after this last one:

no... no, I mustn't.

from depject.

I agree concat was terrible, but depject relives most of the pressure on order, because dependencies (needs) and exports (gives) are explicitly described. If a module does not call anything syncronously in it's create method there won't be problems with order. One pattern is to use setImmediate to delay setup like that. In early versions of depject (before 3) module dependency was resolved and loaded in order, but cycles broke that.

I also worry a bit about ordering. avoiding ordering makes merges easy! but some ordering is hard to avoid.

from depject.