Repository: create-react-app
Issue: "Invalid dependencies" deprecation warning when following official Sass guidance
Labels: needs triage

I have a fresh CRA(-with-TypeScript) app that I've added Sass to by following [this official guidance](https://create-react-app.dev/docs/adding-a-sass-stylesheet/), 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:
```scss
$body-padding: 1rem;
$body-bg-color: magenta;
$body-text-color: yellow;
```
Which is used by the following src/App.scss file:
```scss
@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:
```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](https://user-images.githubusercontent.com/2304574/165365722-514c7a6d-6525-4a48-aa7f-23158965fd94.png)

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`.
```scss
@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`](https://github.com/material-components/material-components-web) 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](https://create-react-app.dev/docs/adding-a-sass-stylesheet/) (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?
1. Why is nobody else running into this?
    1. Are we the only weirdos using `@material` with React?
    1. Do most other multi-package SCSS libraries (that people commonly use with React) do this
        ```scss
        @use "../other-package/variables" as other-package-variables; // 75% sure webpack would be fine with this
        ```
        where `@material` does this?
        ```scss
        @use "@material/other-package/variables" as other-package-variables; // 100% sure webpack hates this
        ```
1. Anyone have any silky-smooth workarounds?
1. 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.