"Invalid dependencies" deprecation warning when following official Sass guidance

[PsiRadish]

I 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:

1. Is nobody else really running into this?
2. Why is nobody else running into this?
   1. Are we the only weirdos using @material with React?
   2. Do most other multi-package SCSS libraries (that people commonly use with React) do this

      @use "../other-package/variables" as other-package-variables; // 75% sure webpack would be fine with this
      

      where @material does this?

      @use "@material/other-package/variables" as other-package-variables; // 100% sure webpack hates this
      

3. Anyone have any silky-smooth workarounds?
4. 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.

[PsiRadish]

So, already an update: The problems with @material disappeared once we just removed SASS_PATH entirely. Seemed like a lot of things behaved differently (and probably better) once we removed SASS_PATH entirely. You should really update that page I linked to.

[niksauer]

We have the same problem with SASS_PATH='src/assets/styles'. @import 'shared';has been working up to CRA v5:

$ tree src/assets/styles

src/assets/styles
├── _colors.scss
├── _defaults.scss
├── _global.scss
├── _shared.scss
├── bootstrap
│   ├── _components.scss
│   ├── _mixins.scss
│   ├── _setup.scss
│   ├── _utilities.scss
│   └── component
│       └── _dropdown.scss
├── flexibits
│   ├── _ios-button.scss
│   ├── _ios-form.scss
│   └── _ios-text.scss
├── fontawesome
│   └── _setup.scss
└── index.scss

$ cat src/assets/styles/_shared.scss 

@import 'bootstrap/mixins';

@import 'colors';
@import 'defaults';

@import 'flexibits/ios-text';
@import 'flexibits/ios-button';

WARNING in ./src/components/util/ServerError.module.scss (./node_modules/react-scripts/node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[1].oneOf[8].use[1]!./node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[1].oneOf[8].use[2]!./node_modules/resolve-url-loader/index.js??ruleSet[1].rules[1].oneOf[8].use[3]!./node_modules/sass-loader/dist/cjs.js??ruleSet[1].rules[1].oneOf[8].use[4]!./src/components/util/ServerError.module.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/assets/styles/_shared.import"
 * "src/assets/styles/_shared.import.css"
 * "src/assets/styles/_shared.import.sass"
 * and more ...

[ziagrosvenor]

We have had the same problem.

We removed the SASS_PATH from our .env file and set it using path.resolve in a node script instead.

We are using react-app-rewired so this meant adding the following to config-overrides.js

const { resolve } = require('path');

process.env.SASS_PATH =
  resolve(__dirname, './path/to/styles') +
  ':' +
  resolve(__dirname, './path/to/node_modules');

The uglier way we found to fix this without react-app-rewired and path.resolve would be to set it using bash in the package.json , for example as follows

"scripts": {
   "build": "SASS_PATH=\"`cd \"./path/to/styles";pwd`:`cd \"./path/to/node_modules";pwd`\" react-scripts build",
   "start": "SASS_PATH=\"`cd \"./path/to/styles";pwd`:`cd \"./path/to/node_modules";pwd`\" react-scripts start"
 }

[davidhicks980]

@ziagrosvenor's package.json solution worked perfectly for me, but you may have to escape the quote before ;pwd. Also, strong thanks to him/her for giving two possible solutions -- it's surprisingly hard to find an answer to this problem on Google.

To give an additional example with escaped quotes, if you previously had SASS_PATH=src, you could also use the following

"scripts": {
   "build": "SASS_PATH=\"`cd \"./src\";pwd`\" react-scripts build",
}

to enter your sass folder and obtain the absolute path.

[niksauer]

This syntax also works: SASS_PATH=$(cd ./src/assets/styles && pwd) react-scripts start

[pavelspichonak]

This syntax also works: SASS_PATH=$(cd ./src/assets/styles && pwd) react-scripts start

works on IOS, but does not work on windows.

'SASS_PATH' is not recognized as an internal or external command,
operable program or batch file.

[laloparra]

I 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.

[Drew-Daniels]

@laloparra 's tip was the missing piece for me. None of the other answers worked in my case, but once I updated my @import statements from:

@import "App/variables"

to:

@import "src/App/variables"

Everything started working