You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sass has a global namespace so the last definition of a @mixin or @function imported will win.
Consider an app that depends on packageA and packageB, both of which have a dependency on packageX. Depending on how the dependencies on packageX are defined for packageA and packageB It's probable the app will end up with two versions of packageX. Depending on how the importer is built, it may be indeterminate which of the two gets used, or maybe they both get used but one clobbers the definitions of the other.
The way eyeglass handles this is by discovering all the sass modules and doing a semver resolution on their declared versions. If semver compatible, the highest version is used, if incompatible, the newest one is picked with a warning or error depending on configuration.
This implementation does a just-in-time resolution when an import is requested, but that means it can't ensure a consistent resolution across sass files or repeated imports, for sass files that depend on a version specific enhancement in the transitive dependency. Even if this project does a better job at resolving against the right version of the library for a specific import, it's going to cause issues because mixins and functions have a late binding resolution when other mixins or functions are invoked so the last definition will win and may have different behavior or arguments.
If there's some use cases that this addresses that Eyeglass does not we could consider augmenting eyeglass accordingly.
The text was updated successfully, but these errors were encountered:
Sass has a global namespace so the last definition of a
@mixin
or@function
imported will win.Consider an app that depends on
packageA
andpackageB
, both of which have a dependency onpackageX
. Depending on how the dependencies onpackageX
are defined forpackageA
andpackageB
It's probable the app will end up with two versions ofpackageX
. Depending on how the importer is built, it may be indeterminate which of the two gets used, or maybe they both get used but one clobbers the definitions of the other.The way eyeglass handles this is by discovering all the sass modules and doing a semver resolution on their declared versions. If semver compatible, the highest version is used, if incompatible, the newest one is picked with a warning or error depending on configuration.
This implementation does a just-in-time resolution when an import is requested, but that means it can't ensure a consistent resolution across sass files or repeated imports, for sass files that depend on a version specific enhancement in the transitive dependency. Even if this project does a better job at resolving against the right version of the library for a specific import, it's going to cause issues because mixins and functions have a late binding resolution when other mixins or functions are invoked so the last definition will win and may have different behavior or arguments.
If there's some use cases that this addresses that Eyeglass does not we could consider augmenting eyeglass accordingly.
The text was updated successfully, but these errors were encountered: