Add a module system

[JulienCabanes]

• Proposal
• Specs
• Documentation
• Dart Sass
• LibSass

See also the module system project.

---

This is a compilation of issues and wishes about @import

Import CSS files #556

@import "normalize";

Would import sass, scss or css file

There's a plugin for that

Import Once #139

@import-once "foo";
@import "foo" !once;
@depend "foo";

Multiple syntax suggestions for one time import

There is a plugin for that

Import Directory #690

@import "foo";

If "foo" is a folder than it tries to import "foo/_module.scss"

reasonable

Namespaces and Aliases #353

@import "foo" as "bar";

This would put every "foo" components (mixins, vars, placeholders...) in a "bar" package.

What would be the separator ? . or / or \ or :: ?
Where would go the $ and % ? Before or after the namespace ?
What it would look like :

// Mixins
@include bar.baz();
or
@include bar/baz();

// Variables
color: $bar.baz;
or
color: bar.$baz;
or
color: $bar/baz;
or
color: bar/$baz;

// Placeholders
div { @extend %bar.baz; }
or
div { @extend bar.%baz; }
or
div { @extend %bar/baz; }
or
div { @extend bar/%baz; }

// Functions
color: bar.baz();
or
color: bar/baz();

Non-transitive imports #353

if A imports B and B imports C, A shouldn't necessarily see everything from C.
A way of getting around non-transitive imports.

Renaming classes #353

This isn't something I'm 100% sold on, but it has been requested. Maybe the correct way to do this is some combination of namespacing and @extend.

Disabling CSS output #353

Both selectively and wholesale. The importer may want to @extend the rules in the importee but not have them concretely present, or it may want to suppress rules matching a certain selector.

This is also related to #320 :

// A.scss
.foo {...}
.bar {...}

// B.scss
@use "A";
.baz { @extend .foo; }

B output would not contain .foo & .bar definition but only .baz;

Conditional imports #451

@if true {
    @import "foo";
}

It "worked" before but never intended.

Paths

A way to setup shortcut paths (like Require.js)

// No syntax intended, only the purpose
@paths (
    "bootstrap": "../components/bootstrap-sass/vendor/assets/stylesheets/bootstrap"
);

@import "bootstrap";

[lolmaus]

Wow, great job @JulienCabanes.

[Anahkiasen]

In a way there is a plugin for import directory but since it's from Chris I'm pretty sure they know about it :p

[chriseppstein]

Adding #739 to the list which is necessary for #451 as well as any use of SassScript in an import directive.

[KittyGiraudel]

If "foo" is a folder than it tries to import "foo/_module.scss"

I really don't understand where do you get this from. I'd expect folder include to behave like this:

// Import a single file
@import "file"; 
// Import all files from folder
@import "folder/*"; 
// Import all files from all folders from folder
@import "folder/**/*";

Or am I wrong?

[JulienCabanes]

@hugogiraudel this came from #690
The problem with folder/* is you can't control the import order, you would expect an alphabetical one but it's too implicit.
Having a standard _module.scss responsible for importing in the correct order would be better.

[Anahkiasen]

Why not both ? Use an index file if present, otherwise alphabetical ?

[jslegers]

@JulienCabanes & @hugogiraudel & @Anahkiasen :

I love the suggestion made by @Anahkiasen.

An alternate solution would be to have a different syntax depending on what you're loading:

• If the path ends with a letter of number, it's considered a file
• If the path ends with /, it's considered a folder and an index file will be loaded... which could be named _module.scss, _index.scss, _component.scss, _loader.scss, ... Maybe the devs could leave it do users to configure what name they want for their index file? I'm pretty sure we're all unlikeoy to want to give up our personal preference here.
• If the path ends with /*, it's considered a folder and all files will be loaded alphabetically.

Example code

// Import a single file named "file"
@import "file"; 
// Import file "_index.scss" from folder "base"
@import "base/"; 
// Import all files from folder "base" in alphabetical order
@import "base/*"; 
// Import file "_index.scss" from every subfolder of folder "base",
// with folders loaded in alphabetical order
@import "base/*/";
// Import all files from every subfolder of folder "base"
// with both folders and files loaded in alphabetical order
@import "base/*/*";

[KittyGiraudel]

Convention is to use ** for folders, * for files. Henre @import "**/*".

[jslegers]

@hugogiraudel :

I'm not familiar with that convention, but it's but a minor difference...

// Import a single file named "file"
@import "file"; 
// Import file "_index.scss" from folder "base"
@import "base/"; 
// Import all files from folder "base" in alphabetical order
@import "base/*"; 
// Import file "_index.scss" from every subfolder of folder "base",
// with folders loaded in alphabetical order
@import "base/**/";
// Import all files from every subfolder of folder "base"
// with both folders and files loaded in alphabetical order
@import "base/**/*";

[robwierzbowski]

"Renaming classes #353" could be accomplished with "Disabling CSS output #353". Disabling selector output could be said another way — "transform selector to placeholder".

// Pseudocode, no syntax implied
.class {
  color: red;
}

@no-output .class;

.module {
  @extend .class;
}

[apfelbox]

@Anahkiasen I would just do the alphabetical import, without the automatic check for the _modules.scss file. Because if I care for the order of my imports (and can't name them _1-modules.scss or something like that = I already have to be specific) I can be so specific to just write @import "foo/modules";

[aripalo]

This sort of falls under the conditional imports #451, but slighlty different use case:

Currently trying to declare @import within mixin will result to Error: Import directives may not be used within control directives or mixins.-Error.

What I am trying to do is following:

@mixin component($name) {
  .#{$name} {
    @import '/components/#{$name}/#{$name}';
  }
}

@include component('foo');

This would be a great way to enforce "namespaced" styles for the components (in my case, Angular directives which live in their own separate folders with their javascripts, templates, tests and styles), and also allow nice short syntax (that @include component('foo');) for importing them.

[koenpunt]

@robwierzbowski a css placeholder can be defined with %

%class-name {
  color: red;
}

.module {
  @extend %class-name;
}

[andi1984]

I hav to agree with @aripalo:

Some sort of @import directive inside a mixin would be great, especially for including third party styles.

[chriseppstein]

@andi1984 see #739

[RaphaelDDL]

+1 for Paths via variables but specially via something @require-like.

Having aliases for css module partials would be awesome. Implementing a _sass_config.scss to be imported on all files like we do with require_config.js on html (or even having a default file name at project sass root folder that would be self-imported, following the idea of @import 'folder' importing a default _modules.scss inside that folder).

An addition to the idea is to have a keyword pointing to project root folder, for example:

@path(
    'myProjRoot': :sass_root
);

This way we leave sass to resolve the root folder path (as some projects are run in multiple OSes so Windows is C:/ but Mac ~/ and so on) and also because sometimes we want to import one single file - without making a full path alias for it - and having @import "myProjRoot/features/aThing/something" is so much easier/faster to understand than @import "../../../../../../../../../../../features/aThing/something".

[backnight]

Hello, I would like to know where is the current development state of these features ? Especially for a feature like this in less : http://lesscss.org/features/#import-options

=> @import (reference) "filename";

Thank you.

[MrMcGibblets]

Trying to follow the issues to get an understanding where this is, in regards to libSass, it was tagged libsass4.0 and is now tagged 5.0, considering 4.0 has a release goal for 2021, are we not expecting this until after then?

[nex3]

Closing this out because LibSass is now deprecated and we aren't expecting to add any additional features to it.