Less.js: modifyVars non transmis

Je suppose que c'est la même chose que dans # 2772 - voir le milieu de la discussion là-bas (par exemple, modifyVars a pour effet de définir la variable, mais cela vient après que la déclaration d'importation d'intérêt est déjà évaluée ). Mais voir aussi https://github.com/less/less.js/issues/1400#issuecomment -137128461.

En bref, le point est le suivant : l'interpolation de variables dans les instructions d'importation est une chose pratique, mais elle est directement en conflit avec le principe d'évaluation paresseuse. Ainsi, s'il s'agit d'une structuration complexe, il serait préférable de trouver d'autres moyens de réaliser ce type de personnalisation (par exemple, en utilisant différents répertoires pour différents fichiers de thème, puis en définissant l'option paths correspondante pour basculer).

Merci pour la réponse. La variable est mise à jour dans moins de fichiers directement importés par JS, ce ne sont que des fichiers importés par d'autres fichiers moins dont la variable n'est pas mise à jour. Une évaluation paresseuse se produit sûrement dans les deux cas ? Il semble que la logique/configuration de var de modification ne soit pas appliquée/transmise aux fichiers les moins importés. Ou est-ce que je manque quelque chose?

La variable est mise à jour dans moins de fichiers directement importés par JS, ce ne sont que des fichiers importés par d'autres fichiers moins dont la variable n'est pas mise à jour.

Eh bien, c'est plus délicat que cela. Notez que pour que l'évaluation paresseuse fonctionne, le compilateur doit évaluer diverses entités de langage (dans la même portée) par types et non par l'ordre dans lequel elles apparaissent dans le code, du niveau supérieur au niveau inférieur, c'est-à-dire (en gros): importations -> mixins - > variables.
Maintenant, si vous avez <strong i="9">@import</strong> "@{var}"; , le compilateur est obligé d'évaluer la variable donnée avant l'importation (et toutes les importations ultérieures) - et c'est ce qui gâche tout (en général, le résultat d'un tel abus est tout simplement indéfini - il fonctionne dans un cas (la plupart du temps très simple) et pas dans d'autres).

Il n'y a aucun moyen pour le compilateur de garantir un comportement cohérent lorsque deux fonctionnalités directement en conflit sont combinées.

En d'autres termes, ce n'est pas que modifyVars ne "met pas à jour les variables" dans les importations ultérieures, mais les valeurs de variables mises à jour elles-mêmes ne peuvent avoir aucun effet sur les importations de niveau externe (car ces importations sont déjà "terminées").

Et même si la doc dit :

Notez qu'avant la v2.0.0, seules les variables déclarées dans la portée racine ou courante étaient prises en compte et que seuls le fichier courant et les fichiers appelants étaient pris en compte lors de la recherche d'une variable.

... ce n'est pas vraiment beaucoup mieux après la v2. Il a amélioré / corrigé plus de combinaisons / cas d'utilisation, mais ne peut pas tous les résoudre. Pour plus de détails, voir #1108 et spécifiquement #2246.

Il semble que la logique/configuration de var de modification ne soit pas appliquée/transmise aux fichiers les moins importés.

Non (simplement parce qu'au final, les fichiers sont évalués tous ensemble comme une seule grande chaîne). A moins que le problème ne soit ailleurs, pour vérifier il suffit d'ajouter :
foo {bar: @theme-variant}
aux fichiers qui vous intéressent et voir le résultat.

D'ailleurs. Pour votre cas d'utilisation (si le "*-theme.less" ne concerne que les variables/mixins pour un thème spécifique), vous pouvez essayer quelque chose comme :

• Laissez la valeur par défaut <strong i="7">@import</strong> "a-theme.less"; pour qu'elle soit explicite (c'est-à-dire sans interpolation) ou supprimez-la complètement.
• Avec modifyVars , définissez l'instruction d'importation elle-même (par exemple, <strong i="11">@import</strong> "custom-theme.less"; directement).

Notez que si modifyVars prétend qu'il ne s'agit que de variables bla-bla-bla - en fait, il ne fait rien d'autre que d'ajouter un texte arbitraire à la fin du fichier racine. C'est-à-dire dans le cas de lessc c'est vraiment juste --modify-vars="whatever-less-code foo {bar: baz;}" . Je ne sais pas cependant quels formats le less-loader de webpack peut traverser, hmm... lessOptions.modifyVars = "an arbitrary code"; peut-être ?

C'est évidemment un hack mais en fait c'est un hack assez prévisible (car il n'abuse que du format modifyVars et non du langage lui-même comme le fait le combo initial).

Merci beaucoup pour vos réponses et vos idées @seven-phases-max Je vais enquêter plus avant au cours de la semaine et j'ai défini un rappel pour mettre à jour/fermer ce problème plus tard dans la semaine. Merci encore.

Je fermerai alors cela car il s'agit plus d'un comportement attendu (défini comme "indéfini/non spécifié" dans ce cas) plutôt que d'un problème qui pourrait être résolu d'une manière ou d'une autre.
Bien que toutes les idées d'amélioration et en particulier les relations publiques soient toujours les bienvenues ... Je ne pense pas que quiconque se lancera dans ce domaine dans un avenir prévisible.