Are angle brackets the right syntax to use when referring to a node module? about eyeglass HOT 21 CLOSED

Thanks for looping me in. I agree that the current format will be confusing to most.

How about something that looks more like Ruby / ES6 string interpolation?

@import "#{my_file_name}/file";

or

@import "${my_file_name}/file";

The dollar sign is my preference between the two since we are dealing with Node modules and that's the ES6 way.

from eyeglass.

I'm hesitant to do that because it's standard sass syntax for escaping to sassscript and users will think they can use variables in there, etc.

An idea I had was @import "~foo/bar.png"; which is borrowing from the unix "home directory" syntax, which may also be a bad idea.

from eyeglass.

I'm not a fan of using ~ here because it's not clear where the module name and path begin.

It seems like there are three approaches to this:

1. Wrap the module name in two identifiers (ie < & >)
2. Begin the string with a non-standard path character
3. Split the string on a non-standard path character

My preference is 1 or 3. Am I missing any alternatives?

Also, I updated my comment above to include ES6 example. Does changing that example to use $ instead of # mitigate your concerns about the sassscript association? Would something else entirely work better (~{file_name})?

Here are a couple other ideas that use the 3rd approach:

@import "susy:susyone";

@import "susy@susyone";

We could split the string on either of these characters to determine the module name and path as needed.

from eyeglass.

Another, more verbose option would be a function syntax: plugin(foo). Not sure that's the right association either — it actually makes me just want the ability to interpolate import strings. :)

from eyeglass.

@aaronagray What would the base import of susy be in your proposal? If you are not grabbing a nested partial, you lose the delimiter: @import 'susy'; unless we require a full @import 'susy:susy';. (I like @ less than : because I can't tell which side is the plugin, and which side is the path).

from eyeglass.

That's a great point, @ericam.

My understanding is that we need to A) identify the node_module folder name, B) determine which file to expose from there, and C) use something that sasscript won't try to import on its own. Are these accurate constraints @chriseppstein? If so, maybe option 3 (described above) won't work. In which case, I'd like to hear thoughts on using the ES6 format.

from eyeglass.

I would like to avoid anything that feels interpolated (e.g. #{...} or ${...}). If they feel like interpolation, I expect interpolation to work (e.g. @import "my/${dynamic}/file").

Instead, I'll propose that we follow a pattern similar to C/ObjectiveC for distinguishing between global vs local includes...

#include "example.h"
#include <example.h>

These will resolve to different files, where the former is a local include and the latter is a global include.

Granted, in our case, this isn't really global vs local, but we can easily take this to mean that one is from my code and the other is from external code.

So I propose that we do...

@import "foo"; // local `foo`
@import "<foo>"; // external `foo`
...
asset-url("<foo/bar.png>"); // external `foo/bar.png`

Note that this proposal wraps the entire path reference in <...>, not just the module name, but the module name will be assumed to be the first dirname.

C++ hasn't had any issues documenting the usage of angle bracket includes, so I think we'll be fine :)

from eyeglass.

@eoneill, I'm happy with that as long as we explicitely document the usage and include an example like the one you provided above. A lot of people don't read, apparently, so as long as we're explicit about including the brackets then we could be safe with most users.

from eyeglass.

Another approach: we could be more verbose. That is the CSS way, right?

@import "module foo";
@import "bar from module foo";
.foo{ background: asset-url("foo.png in module foo");

from eyeglass.

That's starting to look more like @nex3's proposal for advanced imports in Sass. That may be a good tie-in.

from eyeglass.

@chriseppstein I like this best so far.

from eyeglass.

I don't like that @chriseppstein :)

It feels like an awkward/broken ES6 import statement.

from eyeglass.

I'd like to keep it simple. Perhaps we even err further on the side of npm nomenclature.

• starts with a ., it's a relative include
• starts with /[a-z0-9]/i it's a node module include

At least then there's no learning curve for people already familiar with node.js and npm. We can also just refer to those docs on module / id resolution.

Resolution would be of "foo/bar" (when using eyeglass):

1. attempt to look for node module foo with a bar import (node.js resolution)
2. fall back to the default importer (sass) which would check for ./foo/(_)?bar{.css|.scss|/index.scss}

This means that when using eyeglass, you should really use relative paths explicitly for relative things.

from eyeglass.

I tend to prefer readable & explicit over short and clever when reasonable, so that's my vote. I also think we should be consistent with the direction of advanced sass imports (if those are still in the plans). I know it can feel bulky to advanced users, but that's what text-editor snippets are for. I don't want to make users look up the node docs to know what a sass import is doing.

from eyeglass.

It seems to have a lot to do with our perspective on eyeglass. From the Sass side, the more verbose approach makes sense. From the node side, staying as true as possible to the require() logic through either module resolution or some sort of </> demarcation makes sense.

Eyeglass has the enjoyable(?) position of sitting squarely between these two worlds. This is probably as much a philosophical discussion as a technical one.

from eyeglass.

Just spitballing but.

@import "lens foo"; //eyeclass modules are called "len's"
@import "bar from lens foo";

// or maybe supply it as a function to make it more declarative like susy 
lens('foo');
lens("bar from foo");
lens("bar as baz from foo");
lens-asset("bar.png from foo") 

I'm more for this verbose sentence style import syntax then I would be for the proposed @ or : Using those in import declarations just seems gross to me from a code readability standpoint and the sentence style is also more declarative.

from eyeglass.

#27
I'm just throwing some code up. This would remove the < and > entirely. It would also allow us to adopt the proposal for advanced imports that @ericam mentioned when Sass => libsass => node-sass adopt it.

At that point, the "eyeglass" importer's job is to automatically check your node modules on your behalf and not much more, falling back to a native Sass import if there is no node.js resolution.

from eyeglass.

Ok, after sleeping on this, I think @jakobo has the right of it. Even though we are using a custom importer, we should not need any special syntax, the importer simply acts as if we put the eyeglass modules on the load path. The first directory will be checked if it is an eyeglass module and if it is, we import as if it had been wrapped in angle brackets.

from eyeglass.

+1. That seems best. I like that we can document this in one place whereas something like angle brackets would require more explanation in more places.

from eyeglass.

👍 for @jakobo's proposal for npm style. It'll also make sure that things written in node-sass with Eyeglass have a chance of being compatible with Ruby Sass.

from eyeglass.

This landed on master.

from eyeglass.