-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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: