question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

"Invalid dependencies" deprecation warning when following official Sass guidance

See original GitHub issue

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

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.

Issue Analytics

  • State:open
  • Created a year ago
  • Reactions:7
  • Comments:7

github_iconTop GitHub Comments

2reactions
ziagrosvenorcommented, Jun 17, 2022

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"
 }
0reactions
laloparracommented, Dec 27, 2022

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Deprecation Warning in Bootstrap SCSS - Stack Overflow
scss file from bootstrap sass. However, I get a chain of many Deprecation Warnings when I import and compile the 3 required components....
Read more >
Dart Sass Command-Line Interface
This flag tells Sass not to emit deprecation warnings that come from dependencies. It considers any file that's transitively imported through a load...
Read more >
sass-loader - webpack - JS.ORG
This allows you to control the versions of all your dependencies, and to choose which Sass implementation to use. Note. We highly recommend...
Read more >
Sage "9.1": Please test - Roots Discourse
We're using gulp-sass package that is only a wrapper for node-sass. We encounter lots of deprecation warnings like: DEPRECATION WARNING: Passing ...
Read more >
Deprecations by version - GitLab Docs
In preparation for this, the following legacy DAST variables are being deprecated ... x.x will display a deprecation warning in the pipeline's Security...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found