Sage "9.1": Please test

Hmmm - so I deleted 4.0.5 and tried 4.0.4 and same issue - then tried 3.9.0 and it works. So something within the Soil plugin itself? Works in Sage 10 so guessing something is optimised in newer versions for Sage 10.

Alright, your observation is indeed correct. Soil now uses a different theme support key and an array for the options:

You have to replace the existing Soil-related lines in Sage 9.x (and currently 9.1, I plan to fix that):

     * Enable features from Soil when plugin is activated
     * for Soil 3.x
     * @link

     * Enable features from Soil when plugin is activated
     * for Soil 4.x
     * @link
    add_theme_support('soil', [
        // 'google-analytics' => 'UA-XXXXX-Y', // @TODO: Add Google Analytics site key
1 Like

Hi @strarsis - thanks, that works.

Hi @strarsis!

Just followed the instructions in the original post setting up with Bootstrap 4. On running yarn build I get the math division errors already noted above, but I’m also getting

99% done plugins FriendlyErrorsWebpackPlugin

 ERROR  Failed to compile with 1 error                                              15:07:10

 error  in ./resources/assets/styles/main.scss

SassError: 0.25rem and 0 are incompatible.
9 │       $return: append($return, max($value, 0));
  │                                    ^^^^^^ 0.25rem
  │                                            ━ 0
  node_modules/bootstrap/scss/mixins/_border-radius.scss 9:36   valid-radius()
  node_modules/bootstrap/scss/mixins/_border-radius.scss 19:20  border-radius()
  node_modules/bootstrap/scss/_images.scss 18:3                 @import
  node_modules/bootstrap/scss/bootstrap.scss 14:9               @import
  resources/assets/styles/autoload/_bootstrap.scss 4:9          @import
  resources/assets/styles/main.scss 4:9                         root stylesheet

asset scripts/main.js 241 KiB [emitted] (name: main) 1 related asset
asset scripts/customizer.js 3.76 KiB [emitted] (name: customizer) 1 related asset
webpack compiled with 2 errors
error Command failed with exit code 1.

This is without any other customisations, straight from the repo.

So far I haven’t been able to track down a fix and will come back if and when I do, but posting here to see if anyone has any suggestions.

EDIT: this is something introduced with dart-sass 1.40.0. "sass": ">=1.32.0 <=1.39.2", in package.json works as expected.

Yes, this also seemed to me as a bug, as 0 should match any unit.
So after updating dart-sass the issue was fixed? Then I should check and update it in update branch, too.

The issue is with version 1.40.0. Downgrading from that worked. 1.41.0 has now been released which also works, so for future readers, just make sure you’re not using 1.40.0 and you’ll be fine. @strarsis that probably means using "sass": "^1.41.0", in package.json instead of my earlier suggestion.

Why not use Sage 10 now?

IMHO there are two primary reasons why developers decide to still use Sage 9.x:

  1. A legacy Sage 9.x-based project that doesn’t build anymore because of dependency rot/node incompatibilities.
  2. Being very familiar with Sage 9.x and webpack. Sage 10 uses laravel-mix that generates webpack 5 configuration, so it can add a new layer of complexity and issues. Learning a new Sage can take time, hence using a familiar release that got most bugs ironed out can be a good idea sometimes.

I still have some Sage 8.x based sites - and they work fine. Migrating these to Sage 10 would cost time that I currently can’t afford. And also those themes tend to get improved over time, migrating to a completely new base theme can introduce new bugs.


@AurelianSpodarec @strarsis

In addition to these reasons, I’m also waiting for a new theme development guide/pdf as was released with previous editions. :crossed_fingers:

I’ve found there is usually a lot of really useful information in the guides that would otherwise get overlooked.


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 :sweat_smile: 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. :slight_smile:

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