@import is ambiguous about relative vs. absolute paths

/cc @hcatlin @akhleung

When Sass (or libsass) encounters @import 'foo', it searches first in the directory of the source file, and then in all the load paths.

Other languages tend to keep relative and absolute imports separate. For instance Ruby has require and require_relative, and Node distinguishes require('foo') (absolute) and require('./foo') (relative).

Quick background why I care: I’m working on a Sass plugin for Broccoli, and one of the big motivators for making Broccoli was making it easier to share frontend JS + CSS code, because we can now use Bower with Broccoli on top. I know people have been distributing Sass files before (e.g. on RubyGems) but I want to see much more of that, and with less friction. I want libraries that depend on other libraries. So now I really care about getting the semantics of @import right.

Having @import be both absolute and relative seems like it might cause problems when there are ambiguities.

I wonder if we should, at some point, change the @import semantics to be unambiguous. For instance, on the next major version of Sass, we could print deprecation warnings on relative @imports that don’t begin with a dot, so that @import 'foo' is absolute, and @import './foo' is relative.

What do you think?

[bughit]

You say it’s ambiguous, but the semantics are well-defined: a relative import is preferred if one exists. This is how Python’s module system works, for example.

So that means that file naming in a sub-folder is constrained by whatever happens to be in the load path, if you want to refer to both the shadow and the shadowed? That does not seem reasonable.

That along with the ambiguity (you can’t tell from the @import statement if it’s relative or not) makes this far from ideal.

Doing relative lookup only for ./ or …/ eliminates the ambiguity and removes naming constraints.

[joliss]

So I guess what I’m saying is, if I were designing the @import directive from scratch today, I’d probably make it always absolute, unless it begins with ./ or ../.

Now that @import exists already, it’s less clear to me whether it’s worth changing. If the upcoming reworking in 4.0 breaks many imports anyway, it might be worth cleaning this up at the same time, provided that you agree.

(I just noticed that AMD uses this convention as well, by the way.)