[Résolu] Changements dans SASS mal documentés avec @use

Bonjour,

alors maintenant, avec SASS il ne faudrait plus importer des 'partials' avec @import mais avec @use mais c'est mal documenté et je n'arrive pas à le mettre en place.

dans le fichier principal, ici styles.scss il faut utiliser @use en mentionnant un namespace

@use '01-variables' as vars;

ensuite je définie des variables dans un fichier




ensuite, dans un 'partial' j'utilise une variable en la faisant précéder du namespace mais quand je compile ça génère une erreur....




Je travaille avec l'extension Live sass de VS Code

c'est quoi le problème?
Modifié par lionel_css3 (21 Jul 2025 - 17:45)

Salut Lionel,

Tu m'en apprends une. Si je comprends bien, il va y avoir du namespace. As tu essayé d'utiliser l'interpolation ? Ce qui donne :

.bg-lg-primary{
    background-color: #{vars.$primary};
}

pas fan, de ce style d'écriture. Ça rajoute du bruit.

edit : Je viens de passer sur la doc officielle. On voit un billet dans le blog qu'@import est déprécié. Mais quand on regarde la doc, je ne vois pas ta syntaxe. J'ai peut être loupé quelque chose
Modifié par Niuxe (21 Jul 2025 - 18:38)

Houla, l'introduction de @use et @import déprécié sur SASS ça fait un moment déjà ! Du moins si mes souvenirs sont bons, vu que SASS je ne l'utilise plus depuis un bout de temps déjà...

Le namespace, ce n'était (n'est) pas optionnel ? Oui parce que, pour moi, SASS c'est du passé.

J'ai utilisé SASS il y a 15 ans, pendant environ 2-3 ans, j'ai construit avec mes premiers frameworks frontend. Puis Stylus durant des années ; le best. Puis le développement de ce dernier ayant été abandonné, la mort dans l'âme j'ai dû me résoudre à repasser à SASS... j'ai tenu deux.jours ! En effet je n'ai pas supporté la lourdeur de ce machin, après Stylus repasser à SASS était devenu insupportable. C'est à ce moment-là que je m'étais mis à niveau sur SASS et que j'avais découvert @use. C'est aussi à ce moment-là aussi que j'avais remarqué des bugs avec le nested dans SASS, et pour moi ce genre de régression c'était juste pas possible. J'en ai vu d'autres mais je ne sais plus lesquelles, de mémoire il avait des conflits entre les fonctions SASS et les nouvelles fonctionnalités CSS. Après cela, depuis trois ans je crois, je suis passé en CSS vanilla, celui-ci étant désormais mature, à l'exception des custom properties non prises en charge dans les médias queries (du moins pour l'instant). Pour pallier j'utilise donc un peu de PostCSS... mais pas trop, parce que, lui, c'est du TRÈS GRAND bricolage (malgré la hype dont il a bénéficié à un moment donné) : l'écosystème est très fragile car il repose sur des plugins pas toujours maintenus. Certains d'entre eux, très important dans l'écosystème, ont été abandonnés purement et simplement, il faut donc les choisir avec circonspection. En réalité seul deux ou trois plugins sont nécessaires et, idéalement, ils ne font pas le café, ils n'ont chacun qu'une seule responsabilité.
Modifié par Olivier C (22 Jul 2025 - 01:14)

Olivier C a écrit :

Puis Stylus durant des années ; le best.

Dans le monde professionnel, Stylus est inexistant. D'ailleurs, je ne suis pas du tout fan de sa syntaxe. Au passage, j'utilise la syntaxe scss. Je ne suis pas du tout fan de la syntaxe sass.

Olivier C a écrit :

En effet je n'ai pas supporté la lourdeur de ce machin, après Stylus repasser à SASS était devenu insupportable.

Lourdeur ? Pas chez moi. J'avoue qu'avec Grunt ou Gulp, ça pouvait être lourd. Mais depuis rollup, esbuild et ViteJS, la "compilation" est instantanée. Là où ça peut poser quelques problèmes chez moi, c'est lorsque je souhaite écrire quelque chose de nouveau. Il m'est arrivé que j'ai une belle erreur de syntaxe. Or, il n'y en avait pas. Pourquoi ? Parfois, le bundler pose problème. Je pense que le sass a influencé le css actuel. Je ne serai pas étonné que demain, il y ait des if, for, each pour le css.

Olivier C a écrit :

Pour pallier j'utilise donc un peu de PostCSS... mais pas trop, parce que, lui, c'est du TRÈS GRAND bricolage (malgré la hype dont il a bénéficié à un moment donné) : l'écosystème est très fragile car il repose sur des plugins pas toujours maintenus.

J'ai toujours pensé que postcss, c'est la même chose que modernJS ou requireJS. La librairie qui s'utilise pendant la mode. Et, il y a mieux par la suite. Des librairies qui ont fait plouf, il y en a un paquet... Brunch, bower, Angular 1, BackboneJS, GruntJS, requireJS, modernJS, solidjs, dojo, etc.

SASS a été une révélation pour moi. J'ai toujours cru en cette librairie dès le départ. Je n'ai jamais cru en Less. Surtout qu'au départ, ce n'était pas terrible.

En général, je suis méfiant sur la pérennisation d'une nouvelle librairie. À quoi bon apprendre une librairie si demain, elle est déjà désuète.
Modifié par Niuxe (23 Jul 2025 - 18:58)

Je ne veux pas qu'on me conseille un autre outil que SASS (Ton chat est malade et tu sais pas le soigner, tu le tues et tu prends un chien à la place?), mais qu'on puisse me dire pourquoi mon exemple, tiré de la doc, ne marche pas....


Modifié par lionel_css3 (23 Jul 2025 - 10:58)

lionel_css3 a écrit :
Je ne veux pas qu'on me conseille un autre outil que SASS (Ton chat est malade et tu sais pas le soigner, tu le tues et tu prends un chien à la place?), mais qu'on puisse me dire pourquoi mon exemple, tiré de la doc, ne marche pas....

Change d'ordi ! Tu sais Windows, c'est lui le problème

Plus sérieusement, pourquoi ne fais-tu pas des import ? Si besoin, tu namespace tes vars ou mixins. En ce moment, je suis sur un petit projet et pas de souci au niveau des imports et récupération des vars/mixins. La version de Sass que j'utilise est la 1.86.0

Edit: il n'y a pas longtemps, j'ai fait un mini projet avec fastapi. Je devais utiliser Jinja. Après quelques manips pour deboguer, j'ai dû downgrader la version de fastapi parce que tout simplement, ça ne fonctionnait pas.
Modifié par Niuxe (23 Jul 2025 - 19:06)

Niuxe a écrit :



Plus sérieusement, pourquoi ne fais-tu pas des import ?

les @import génèrent un warning message comme quoi cela sera 'deprecated'' prochainement, c'est pour ça que j'ai créé ce post

J'ai trouvé cette vidéo qui explique comment remplacer @import par @use et aussi utiliser @forward.

Cette vidéo à 4 ans et le gars disait déjà que @import était déconseillé.
Il dit aussi que l'extension Live Sass (que j'utilise) de VS Code nétait pas compatible; mais depuis 4 ans elle a peut-être été mise à jour.

J'ai regardé la vidéo une fois mais je la reprendrai à tête reposée...

En prenant un peu de recul, c'est assez simple. Si ton projet est appelé à être mis à jour continuellement (changement de version de paquets régulièrement), il est judicieux de mettre à jour la syntaxe.

Perso, sur le projet sur lequel je suis actuellement, j'ai quelques warning. Ça ne m'empêche pas d'utiliser sass. À priori, je ne pense pas changer de version du paquet sass.

amusant ce lien : https://sass.js.org/
Modifié par Niuxe (24 Jul 2025 - 00:19)

Bonjour,

La règle @use est supportée uniquement par l'implémentation Dart Sass qui ne semble pas être celle utilisée par ton extension vs code.
Voir à la place https://marketplace.visualstudio.com/items?itemName=codelios.dartsass

Au passage, tu peux utiliser la syntaxe

@use 'variables' as *;

pour charger les variables sans namespace.
Modifié par Pitet (24 Jul 2025 - 10:48)

Suite à ma solution, une remarque avec l’extension Live Sass de VsCode:

Elle est parfaitement compatible avec @use et @forward, c'est elle que j'ai utilisée.

Kevin Powel dit dans sa vidéo que l'extension n'est pas compatible, mais c'était il y a 4 ans.
Depuis il y a eu une nouvelle version de l'extension, écrite par Glenn marks, c'est celle ci qu'il faut utiliser et ça compile parfaitement:



Je préfère utiliser Live Sass plutôt que d'installer Sass via npm avec des dossiers node_modules partout...

il suffit juste de bien configurer Live Sass dans chaque projet avec un fichier settings.json spécifique dans un dossier .vscode à la racine du projet, et d'ailleurs il faut vraiment le faire sinon l'extension compile tout les fichiers scss qu'elle trouve (bonjour, quand on fait ça à la racine d'un Wordpress sans prendre la précaution, lol)

Pitet a écrit :
Bonjour,

La règle @use est supportée uniquement par l'implémentation Dart Sass qui ne semble pas être celle utilisée par ton extension vs code.

mais l'extension est compatible quand même (voir juste au dessus)

Pitet a écrit :
Bonjour,


Au passage, tu peux utiliser la syntaxe

@use 'variables' as *;

pour charger les variables sans namespace.

Oui, j'avais vu aussi, mais comme j'aime la spécificité, je préfère ajouter le namespace, c'est une habitude à prendre...