Does node-sass support @use, and @forward? #2886
Comments
|
No it's not supported yet |
|
@xzyfer May I ask if it is at least on a roadmap? As Can we at least have a warning? Like |
|
@xzyfer could this issue be reopened, if only so that that this can be used as a reference in discussions of a development roadmap? As things go, 1 October 2021 will be upon us in no time. I for one was starting to develop a small framework for vue, but now that I'm seeing that almost no-one uses the dart-sass compiler, I realise that I can't justify incorporating What is the roadmap for the new Sass modules features? |
|
People who are looking for solutions (and maybe now alternatives) I can verify that the JS-based module endorsed by Sass team is supporting these features and it works with |
|
@latobibor Are you referring to the Dart Sass implementation? While it works and supports the full Sass feature set, it has a few shortcomings including:
The last point is a killer if you are working on something that you would like to have as few barriers as possible to integration and adoption. Interesting aside, but I wonder why there are two versions of dart sass on npm: sass v 1.26.5, and dart-sass which is pegged at 1.25. Relevant SO thread: (https://stackoverflow.com/questions/56150402/vue-cli-css-pre-processor-option-dart-sass-vs-node-sass) |
|
@orionrush Yes, I was referring to the Dart Sass implementation and the , which is now the officially supported implementation by the Sass team: https://sass-lang.com/dart-sass
The package sass is the purely JS version, which is slower but works like a charm. |
|
@latobibor that makes total sense, in the context of a project you control, for yourself or as a team decision. However, as someone interested in producing a sass toolset for wider use, forcing users to adopt the Dart Sass implementations for their project will be a deal-breaker for many. It would certainly prevent many folks from integrating into a pre-existing project that already uses node-sass. The question is, is there an appetite/roadmap for bringing |
|
Agree with @orionrush that it'd be great to reach parity with |
I agree that in the meantime some warning or documentation of this in could save a lot of time. |
|
Well, the documentation of these features on the sass websites are showing that they are not support by libsass (which is the implementation used by node-sass) |
|
Unfortunately the SASS team has decided to deprecate LibSass and will not adding support for |
* Reformatted .inc and our packackage.json to have consistent 2 spaces of padding * changed all var's to const/let * removed extended data as unused * removed leading zeros from scss files. This is more consistent with the style used across most of the project * removed object shorthands. This way is more consistent across the existing codebase * switched from the rgba to the rgb css widget. Reasoning is, that it seems a bit more readable and browser support is there: https://caniuse.com/mdn-css_types_color_rgb_alpha_parameter * removed useless extra clutter in the scss files, which stylint wants * whitespace changes for js files * removed .scss from scss imports for consistency * Changed aditional var to const/let * Removed curly string and console warnings, as they are more noise than signal * fixed non scss compliant use of rgb added stylelint-scss to the plugins * changes to make scss files compliant: - modules should be used instead of raw global functions - `border: 0;` is more constinent to `border: none;` - Only let stylint run over css files (it has some isues with the vue syntax) * removed the unused function GETRequest() * history=>window.history * Used Object.values instead of for..in Reason: for..in loops iterate over the entire prototype chain, which is virtually never what you want. Use Object.{keys,values,entries}, and iterate over the resulting array * added globals for the common js globals * allowed dangling underscored and made more things contain underscores * fixed how for loops are used: .forEach is superiour to for..of due to Polyfills and other issues * moved addEventListener to document.addEventListener * prefered explicit function-arg defaults, instead of exchanging after the fact * moved regenerator-runtime to npm * removed CustomEvent polyfill (for IE) * mostly unified the functions (named,unnamed, arrow) used by JS gulpfile.js is the odd one out. * migrated from node-sass to dartSass. Reasoning: sass/node-sass#2886 * reordered the dependencies in the package.json: - only things that modern browsers use are getting delivered are listed as dependencys. - polyfills/build tooling is listed as below the other Dependencies, because while included in prod, they are only delivered to a minority of users * replaces navigatum.cloneState with the buildin structuredClone see https://caniuse.com/mdn-api_structuredclone with a polyfill for samsung internet * added conditional feedback.js minification * changed the method how we rename files in the gulpfile * added better maintianed version of spectre.css Co-authored-by: octycs <octycs@users.noreply.github.com> Co-authored-by: octycs <git@octycs.eu>
I have used @use, and @forward, but it seems, they are not yet supported in LibSass?
The text was updated successfully, but these errors were encountered: