We recently encountered an issue where we attempted to run a Grails 3 app on Windows using a packaged plugin, where the plugin assets contained SASS files with relative imports.
E.g. we had a parent SASS file in the plugin with @import ../../common/vars to include a common set of variables stored two directories "up" within the same plugin's assets.
The asset pipeline threw trying to compile this parent SASS file with an "import not found or unreachable" exception. Some debugging revealed that the method responsible for resolving imports into AssetFiles - SassAssetFileImporter.getAssetFromScssImport() - was generating candidate paths with the Windows \ delimiter, then passing those into AssetHelper.fileForFullName(), which loops through all available resolvers and attempts to find the file.
The resolver that should have located the file was the ClasspathAssetResolver, since the assets in question were part of the plugin and available via the CP. However that depends on the path slashes being / and failed with the Windows-specific slashes generated by the SassAssetFileImporter.
Not sure at what level of the code the paths should be normalized... For now, we are registering our own additional extended/patched classpath resolver that swaps the slashes out, but would love any suggestions for a fix within the plugin. Thanks!
We recently encountered an issue where we attempted to run a Grails 3 app on Windows using a packaged plugin, where the plugin assets contained SASS files with relative imports.
E.g. we had a parent SASS file in the plugin with
@import ../../common/vars
to include a common set of variables stored two directories "up" within the same plugin's assets.The asset pipeline threw trying to compile this parent SASS file with an "import not found or unreachable" exception. Some debugging revealed that the method responsible for resolving imports into AssetFiles -
SassAssetFileImporter.getAssetFromScssImport()
- was generating candidate paths with the Windows \ delimiter, then passing those intoAssetHelper.fileForFullName()
, which loops through all available resolvers and attempts to find the file.The resolver that should have located the file was the
ClasspathAssetResolver
, since the assets in question were part of the plugin and available via the CP. However that depends on the path slashes being / and failed with the Windows-specific slashes generated by the SassAssetFileImporter.Not sure at what level of the code the paths should be normalized... For now, we are registering our own additional extended/patched classpath resolver that swaps the slashes out, but would love any suggestions for a fix within the plugin. Thanks!