search

atomify / atomify-css

Atomic CSS - Reusable front-end styling using Rework, plugins, and Node's resolve algorithm
MIT License
78 stars 18 forks source link

Nested dependencies #4

Closed anthonyshort closed 10 years ago

anthonyshort commented 10 years ago

Just out of curiosity, how does this handle nested dependencies?

If two modules depend on another module, but different versions, will both versions be included in the final build? If so, this doesn't really work for CSS single there isn't any scope.

Does it flatten the tree so that you only get one version of each dependency? I realize in practice, most CSS modules don't depend on other modules that much since it's all tied together in the DOM anyway.

techwraith commented 10 years ago

This is a problem that we haven't really needed to solve yet. You're right that there is the potential for conflict here. Luckily, we only use the "first" module that we find. Any other versions of that module get skipped.

There are probably better ways to handle this, but like I said, we haven't needed to yet.

On Tuesday, January 14, 2014, Anthony Short wrote:

Just out of curiosity, how does this handle nested dependencies?

If two modules depend on another module, but different versions, will both versions be included in the final build? If so, this doesn't really work for CSS single there isn't any scope.

Does it flatten the tree so that you only get one version of each dependency? I realize in practice, most CSS modules don't depend on other modules that much since it's all tied together in the DOM anyway.

— Reply to this email directly or view it on GitHubhttps://github.com/Techwraith/atomify-css/issues/4 .

anthonyshort commented 10 years ago

Yep, totally understand. We have the same issue with Component, but it turns out to not really be an issue because CSS doesn't work that way.

It becomes more of a problem if you were trying to manage Sass because mixins and placeholders will be shared around. Which is why I don't use Sass anymore :)