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.
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"
Result: importless spits out a sorted array, without imported file and without ignored files.
To make this work and to avoid confusion, importless needs to be changed in some ways.
// @define ...
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 @.
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?
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.
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?
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?
As @boennemann pointed out, every module should be a mixin, which does avoid conflicts. We need to solve #5.