@use and @forward rules should now follow the order discussed in #46, with the built-in module @use rules inserted immediately before the first existing import and the additional @use and @forward rules inserted immediately after the last existing import.
Code changes to make this happen:
Instead of one additionalUseRules sets, this is now split into three sets for built-in modules, load paths, and relative paths.
~With this change, there are now eight different properties that are reset for each stylesheet in _ModuleMigrationVisitor.visitStylesheet. To reduce the boilerplate in this method, I extracted them out into a separate class so they can all be reset at once.~
~The text of a Patch is now mutable to allow an @import->@use patch to be changed to an @import->@forward patch without changing the patches' order (trying to track these patches separately and then add them later caused a lot of issues, mostly with @import rules with multiple imports)~
I replaced getMigratedContents in MigrationVisitor with beforePatch, since we now needed to add patches after visiting the stylesheet but before patches and currentUrl are reset for the next stylesheet. addPatch now has an additional optional parameter to add patches to the beginning of the list, to resolve similar issues to the above with multiple patches at the same insertion point.
Resolves #46. Resolves #88.
@use
and@forward
rules should now follow the order discussed in #46, with the built-in module@use
rules inserted immediately before the first existing import and the additional@use
and@forward
rules inserted immediately after the last existing import.Code changes to make this happen:
additionalUseRules
sets, this is now split into three sets for built-in modules, load paths, and relative paths._ModuleMigrationVisitor.visitStylesheet
. To reduce the boilerplate in this method, I extracted them out into a separate class so they can all be reset at once.~Patch
is now mutable to allow an@import
->@use
patch to be changed to an@import
->@forward
patch without changing the patches' order (trying to track these patches separately and then add them later caused a lot of issues, mostly with@import
rules with multiple imports)~getMigratedContents
inMigrationVisitor
withbeforePatch
, since we now needed to add patches after visiting the stylesheet but beforepatches
andcurrentUrl
are reset for the next stylesheet.addPatch
now has an additional optional parameter to add patches to the beginning of the list, to resolve similar issues to the above with multiple patches at the same insertion point.