Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Ship a built-in package importer #2739
There's currently no standard way for Sass users to import packages from dependencies. There are a number of domain-specific solutions, such as Webpack's tilde-based imports,
Most of these have the disadvantage of needing to be explicitly opted-into, and all of them make it difficult to share stylesheets across different contexts. For example, if package A depends on package B, how can A import B in a way that will work in both Webpack and in Dart?
This is the kind of situation where centralization is a boon. If we can build into the Sass language a notion of a "package import" that's flexible enough to work across contexts, we can make it usable by all stylesheets with confidence that even if they're used by different build runners or even ported to a different package manager their dependencies will continue to work.
What does it look like?
The Sass specification talks about imports in terms of URLs. The current JS API deals with them as a combination of raw strings and filesystem paths, but I'd like to move away from that as part of #2509.
The current most popular solution for package imports is probably
We'd have a similar problem if we automatically added
As such, I propose that we use the URL scheme
What does it do?
The purpose of a standard package importer is in fact to avoid specifying the exact behavior of the importer, so that it can do something sensible for each context. However, since Node.js is by far the most popular context in which Sass is used, we should figure out what it does in that particular case.
When resolving a URL, I think it should check
There's a convention of npm packages declaring their Sass entrypoints using
I personally like the tilde approach Webpack offers, but reading the issues it introduces,
I'm personally ok with that.
As a Bootstrap maintainer I can confirm we get some questions from people asking if this can be simplified.
I like the idea of an entrypoint but I prefer
For package imports, I agree the approach
As for the style and sass keys in package.json, why not using the
As for the tilde, I really find it convenient if you are authoring the lib with something like
This is my proposal through examples:
File structure of our package
Lets say that This can be the structure of our package:
Backwards-compatibility is definitely important
The underscore is the same partial indicator Sass has always had.
Both of these use-cases will work; Sass already supports index files for any directory.
For the same reason that I'd like to avoid the
Unless I'm mistaken, this isn't valid
I agree for the most part, although I'm not sure what it would mean for this syntax to work with Sass files that have absolutely no context—how would we even start knowing how to resolve imports?
While I think Node and
Adding a git submodule to
cd some-project mkdir -vp "_sass/modules" git submodule add\ -b master\ --name "vendor-prefixes"\ "https://github.com/scss-utilities/vendor-prefixes.git"\ "_sass/modules/vendor-prefixes"
Initial clones then look something like...
git clone --recurse-submodules <url-for-your-project>
Pulls and fetches involving updated submodules are similar to...
git pull git submodule update --init --merge --recursive
git submodule update --init --merge --recursive --remote git commit -F- <<'EOF' :arrow_up: Updates tracked submodule dependencies # ... anything else worthy of note EOF git push origin master
git submodule status git submodule foreach git branch -vv
cd _sass/modules/vendor-prefixes git status
Module developers, such
... however, I think this could be resolved via some form of
Maybe a better way than explicitly setting up a bunch of mappings would be to have a
One of the things I really like about Sass is the low-barrier to entry, not being required to preform any extra configuration and having a write, compile, and results cycle is wonderful. Where
If I remember correctly
Mainly what I'm getting at is that Git already provides dependency management, and that the
The biggest issue I see with using submodules this way, are with instances of shared dependencies, but like I already stated, I also think this could be worked around. Perhaps through parsing configurations or variables within
IMHO, you don't need to worry about anything else except providing a way to import style files from
It comes down to developers to create good code on either end. With command
Using a specific namespace for functionality that differs from the typical module behavior seems like it could be easily missed while reading through a file, or for newer users to immediately understand. It also would make specific syntax-highlighting for package-related verbiage require specific cases for
My suggestion would be using something like
I think defining a totally separate syntax for package imports that would have identical semantics to