"Invalid dependencies" deprecation warning when following official Sass guidance
See original GitHub issueI have a fresh CRA(-with-TypeScript) app that I’ve added Sass to by following this official guidance, including (and this is the important part) the suggestion of using the SASS_PATH
environment variable to shorten my import paths. So my .env file has
SASS_PATH=./src/styles
And in src/styles I have the following _variables.scss file:
$body-padding: 1rem;
$body-bg-color: magenta;
$body-text-color: yellow;
Which is used by the following src/App.scss file:
@use "variables";
body {
padding: variables.$body-padding;
color: variables.$body-text-color;
background-color: variables.$body-bg-color;
}
Which is in turn imported by the following App.tsx:
import './App.scss';
function App()
{
return (<>
<h1>Super Cool Site</h1>
<p>With profound and super cool content.</p>
</>);
}
export default App;
And all of that runs and compiles and produces a beautiful page with excellently-chosen colors, as expected.
In the npm console, however, there is this obnoxiously large warning about invalid dependencies with non-absolute paths:
WARNING in ./src/App.scss (./node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[1].oneOf[7].use[1]!./node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[1].oneOf[7].use[2]!./node_modules/resolve-url-loader/index.js??ruleSet[1].rules[1].oneOf[7].use[3]!./node_modules/sass-loader/dist/cjs.js??ruleSet[1].rules[1].oneOf[7].use[4]!./src/App.scss)
Invalid dependencies have been reported by plugins or loaders for this module. All reported dependencies need to be absolute paths.
Invalid dependencies may lead to broken watching and caching.
As best effort we try to convert all invalid values to absolute paths and converting globs into context dependencies, but this is deprecated behavior.
Loaders: Pass absolute paths to this.addDependency (existing files), this.addMissingDependency (not existing files), and this.addContextDependency (directories).
Plugins: Pass absolute paths to fileDependencies (existing files), missingDependencies (not existing files), and contextDependencies (directories).
Globs: They are not supported. Pass absolute path to the directory as context dependencies.
The following invalid values have been reported:
* "src/"
* "src/styles"
* "src/styles/_variables"
* and more ...
@ ./src/App.scss 8:6-373 22:17-24 26:7-21 58:25-39 59:36-47 59:50-64 63:6-73:7 64:54-65 64:68-82 70:42-53 70:56-70 72:21-28 83:0-343 83:0-343 84:22-29 84:33-47 84:50-64 61:4-74:5
@ ./src/App.tsx 4:0-20
@ ./src/index.tsx 7:0-24 11:33-36
And included in that warning is the scary text “deprecated behavior”, which means it is only the pupal stage of a future error that will one day crush my application beneath its terrible wings.
This warning goes away if I change how App.scss imports _variables.scss, so that it basically no longer uses SASS_PATH
.
@use "styles/variables";
Which leads me to conclude that any(?) use of SASS_PATH
will provoke this warning; information that is curiously lacking from the official guidance that I linked earlier. But there seems to be a more general issue of “paths with an ambiguous starting point are no longer kosher” that goes bizarrely un-warned-of in any recent discussion of React + SASS that I’ve found. Which makes me feel like I’m missing something.
Obviously the easy fix in my small example app is simply not using SASS_PATH
, but in a larger application SASS_PATH
can be appealing. More importantly, if there are ambiguous paths used in a node_modules
scss file it seems like there’d be nothing we could do about it.
Which is not actually as hypothetical as I made it sound; it’s the exact problem we’re running into in our real application, which has been using @material
for years, but we’re now trying to update it to React 17 and react-scripts 5. @material
’s scss is riddled with @use
paths that start with "@material/
(implicitly relative to node_modules) and the new webpack gives the stinkeye to every single one of them.
Could this be considered a CRA bug? The way it’s not warned about here (or really seemingly anywhere by anyone) gives me strong vibes of, “Oops, we didn’t know that would happen.” No idea if you can do anything about it besides update your documentation though (which, uh, you should totally do, BTW).
Other questions I would like answered, if possible:
- Is nobody else really running into this?
- Why is nobody else running into this?
- Are we the only weirdos using
@material
with React? - Do most other multi-package SCSS libraries (that people commonly use with React) do this
where@use "../other-package/variables" as other-package-variables; // 75% sure webpack would be fine with this
@material
does this?@use "@material/other-package/variables" as other-package-variables; // 100% sure webpack hates this
- Are we the only weirdos using
- Anyone have any silky-smooth workarounds?
- Failing that, what about uncomfortable-or-worse workarounds?
- With the extremely limited knowledge of how webpack works that I’ve gleaned from light useage of
react-app-rewired
, I’m picturing creating some kind of thingy (a “loader”, maybe?) that would be inserted somewhere in the webpack pipeline and intercept all dependency paths, resolving the non-absolute ones into absolute ones before webpack can get its judgemental eyes on them. - Even if you don’t have an alternative, please let me know if the above idea is of comparable viability to a 4-year-old’s theory of how babies are made.
- With the extremely limited knowledge of how webpack works that I’ve gleaned from light useage of
Issue Analytics
- State:
- Created a year ago
- Reactions:7
- Comments:7
Top GitHub Comments
We have had the same problem.
We removed the
SASS_PATH
from our .env file and set it usingpath.resolve
in a node script instead.We are using
react-app-rewired
so this meant adding the following toconfig-overrides.js
The uglier way we found to fix this without
react-app-rewired
andpath.resolve
would be to set it using bash in thepackage.json
, for example as followsI use to have this warning too.
You need to use absolute paths in your sass files like this: @use ‘src/style/variables.scss’
Include the ‘src/[directoryName]/[fileWithVariables]’ in all calls even if the route is not relative from file.