In addition to these reasons, I’m also waiting for a new theme development guide/pdf as was released with previous editions. 
I’ve found there is usually a lot of really useful information in the guides that would otherwise get overlooked.
2 Likes
If you haven’t noticed it yet, the webpack 5 PR was merged into Sage upstream 9.x branch:
So you can now install Sage 9.x as usual, no extra steps required for the fixes.
Addendum: In the meantime lots of webpack tooling changes again… There is an additional branch that tracks changes for the latest changes, but there is no PR yet (GitHub - strarsis/sage at webpack5-url-update).
1 Like
Overlooking the other major reason, the install commands on the homepage, the documentation and default options all install Sage 9, and not even the latest version of 9!
That’s a pretty good indication for someone new to the project that Sage 9 is what to do. I didn’t even think sage 10 was ready. Now running into all these issues with sage 9, seems I’d have been better investing my time learning / installing sage 10. Maybe it’s time to update the homepage and docs?
They install the latest published release of Sage 9 
We’ve been focused on getting Sage 10 out the door and haven’t circled back to Sage 9 yet to give it another release after recent updates from the 9.x. branch.
The advice of a lot of folks on here has been “just use it” for a couple years now. But it’s also pretty well documented, which I hope isn’t a secret? Sage 10 also recently has gotten additional beta releases, Bud is out, Acorn is no longer in beta, and we’re ready to ship. It’s happening any day now. 
Sage 10’s final release will end any confusion about what version should be used.
1 Like
This also fixes the image path issue in 9.0.10: Error: Can’t resolve images/stylesheet (Sage 9.0.10)
As a side effect of using webpack 5 and associated loaders/plugins that correctly work, the paths aren’t relative to the using SCSS files anymore in the latest Sage 9.x release, changelog:
While I migrated everything to webpack 5 I noticed that again lots of stuff changed again and updating/replacing these would result in the previous behavior…
Well, the JavaScript ecosystem, especially the build/bundler tooling is still changing very quickly and is quite unstable with lots of module rot. In an ideal world one would just define a working version of node (using a .nvmrc file and a tool like nvm), and years later (as an extreme example), everything would still install and build fine.
But this isn’t and hadn’t been the case sadly: Just getting the node version right proved to be basically impossible, older node versions do simply not install on newer distribution releases, run or their npm can’t be used, even self-updating npm to a newer, working version is often impossible. This is further exacerbated by the need to use some non-JS libraries, which involves building and linking code. This also simply doesn’t want to work in older node versions. One is simply forced to use a newer node version. And with a newer node version everything else breaks down: The packages aren’t compatible anymore, either formally or simply because of different node ABIs/APIs.
Updating the packages also doesn’t work because of incompatibilities between major releases (and sometimes even between small releases). In the end the whole tooling has to be updated. Getting the associated plumbing stuff right and fixing all the little errors, strangeness and quirks requires a large amount of time. In an ideal world one would simply follow that guide, then some others and the thing just builds. But in the real world the 2nd loader probably already breaks the whole thing.
Even a Vagrant VM with the whole OS and packages may not work, I had so many issues with Vagrant and VirtualBox and bootstrapping the thing. Many Vagrant plugins hadn’t been updated for years.
The latest Sage 10 uses bud that abstracts the plumbing away (similar to laravel-mix, whose development also stalled) which hopefully adds some stability.
Where do I set quietDeps: true to get rid of the warnings?
quietDeps can be set in the sassOptions in the base webpack.config.js of the Sage 9 project:
quietDeps was added about a year ago, and early adopters initially had issues enabling this option by the way, but that would be actually an underlying issue with the dart-sass implementation:
That’s weird, I setup mine like this:
{
loader: 'sass-loader', options: {
sassOptions: {
sourceComments: true,
quietDeps: true,
},
sourceMap: true, //config.enabled.sourceMaps, // false causes a resolve issue
},
},
And I still get:
DEPRECATION WARNING: Using / for division is deprecated and will be removed in Dart Sass 2.0.0.
Recommendation: math.div($spacer, 2)
@intelligence: With sass-loader version 12.0.0 and sass version 1.49.11 the issue can be indeed reproduced. I first tested just with the local usage of /, then I remembered that the actual point of the quietDeps option is to quieten notices/warnings of dependencies. So I tested again by importing the normalize-scss npm package (version 7.0.1, the project hadn’t been maintained for a while now and it uses / that triggers the deprecation warning) and was able to reproduce the issue with the older versions of sass-loader and sass. Updating these to their latest versions fixed the issue.
You are using the latest commit of the Sage 9.x branch. At that time sass 1.49.11 and sass-loader 12.0.0 were the most recent and are specified in package.json.
Initially (the new reference Dart implementation) sass and sass-loader had trouble with the quietDeps options and for some time it hadn’t worked correctly. This has been fixed now apparently.
You need to update the sass and sass-loader packages to their currently latest versions, sass version 1.49.11 and sass-loader version 12.6.0.
A quick way to do that (examples for npm or yarn):
npm i --save-dev sass@1.49.11 sass-loader@12.6.0
yarn add --dev sass@1.49.11 sass-loader@12.6.0
After I updated those sass and sass-loader packages,the deprecation warnings all went away, even without the quietDeps option or it set to false.
can’t see to use the composer command?
GitHub API limit (60 calls/hr) is exhausted, could not fetch https://api.github.com/repos/strarsis/sage. Create a GitHub OAuth token to go over the API rate limit. You can also wait until 2022-04-12 11:28:54 for the rate limit to reset.
Tried creating a token too.
Any thoughts?
1 Like
composer also has to be configured to use a GitHub token (OAuth).
See this good guide, it doesn’t matter that it also mentions Drupal):
This should lift the GitHub API limits considerably, you won’t hit these usually