dependency order

[davidpfahler]

importless needs the ability to define and handle the order of stylesheet dependencies. This would transform the way stylesheet code can be written, maintained and build for production.

Features

Defining stylesheet modules is inspired by require.js. You can define dependencies by inserting a comment line anywhere in your stylesheet file that fits this pattern:

// @define "my/other/file.css", "all/the/*.css", "what/the/hell.less", "forgot/the/fileending"

• comma separated strings
• need to be valid [minimatch] patterns
• you can use other file endings, because importless by itself does not care about the language you use
• whatever is using importless needs to handle compiling to css and changing the file ending (unlike it is currently the case)

Result: importless spits out a sorted array, without imported file and without ignored files.

To Do

To make this work and to avoid confusion, importless needs to be changed in some ways.

• never change files
• do not compile
• detect imports based on files ending (currently only less supported, also css, sass, ...)
• detect order based on // @define ... comment

[boennemann]

I strongly oppose against naming the keyword import, just because that's how it's named in css.

The dependency defenition is nothing more than, well, a definition. Nothing get's imported here, because importless doesn't even compile, minify, or concatenate by itself.

I suggest using define, but beginning with an @.

// @define "my/other/file.css", "all/the/*.css", "what/the/hell.less", "forgot/the/fileending"

[davidpfahler]

Here is a problem I thought of just now regarding dependency management. What if two files where depending, but both files would themselves be imported on two very different levels. The first one very high up in the dependency tree, the other one very deep down. Where would we need to inject the common dependency?

Option 1: On first occurrence only

This makes sense because the css will me set from there on. The problem is that all of the following code could (unintentionally) modify the properties set by our dependencies. By the time the second file is included, its dependency might have been modified significantly.

Option 2: On both occurrences

This would fix the problem of the second file. The second file would get the properties set as it excepts them to be. But that raises the exact oposite problem: What if the changes to these properties where intentional, and now are overwritten by a dependency of something further down the dependency tree?

Conclusion

So either way, I think the dependency management needs a sane explanation so everybody knows what they are doing. A non-linear dependency management is not something anybody is used to is CSS. Because nobody has ever done this before, there are no defaults we can look up to?! Maybe bootstrap?

Solution: Everything is a mixing

As @boennemann pointed out, every module should be a mixin, which does avoid conflicts. We need to solve #5.