I just pulled down a new copy a few days ago. Stylelint is working. Might be something I did when moving things over to from a previous version of the stack.
1 Like
Still having issues with this. The reload was getting slower and slower. Looked at the error console in Chrome and am getting _webpack_hmr error with āFailed to load resource: the server responded with a status of 404 (Not Found)ā. Seems to go into a bit of a loop and keeps looking for it. I think, from reading elsewhere, it has something to do with the Hot Module Replacement of webpack but not sure how to troubleshoot it.
Also tried a yarn build:production and getting a āfailed to compile with 1 errorā with the only clue being: "webpack compiled with 1 error
error Command failed with exit code 1.
Thereās a lot of Dart SASS depreciation messages and a few lint āno-descending-specificityā errors but they shouldnāt be the cause right??
Iām just wondering if Iāve messed about with the whole set-up too much and need to start fresh somehow. Can I extract Sage from Bedrock and finish this in a simpler set up? In over my head and need to deliver a usable site soon.
@d_em: Are you using the latest version of this Sage 9.x update branch?
These issues had occurred in the past in Sage 9.x, but should be fixed with the latest update branch version.
The deprecation notices indicate that you are probably using an older version of the update branch.
The friendly errors webpack plugin has been re-added after some adjustments to latest webpack, and it should now prevent these deprecation messages to be logged permanently to the terminal.
Check out the usage guide at the start of this thread:
It should be easy to update an existing Sage 9.x based theme with the latest update modifications.
@diomededavid: So using the latest version of the update branch fixed all these issues? Are there still issues? I cleanly checked out the last version of update branch and linting during watching works.
Hi @strarsis - yes, installed 9.1 and moved my project over per this thread. Did a clean install of Sage with Local on a different system last night (without bedrock) and all worked OK. Still getting the mass of sass depreciation warnings but at least no webpack hmr issues and seems to work on yarn:production. I think best course of action will be to carefully migrate my project files over to that system and continue there. Good thing is that if forced me to look at every step of the process so have a better appreciation of the environment now. Skipped Bedrock as not confident in pushing this to a live server next week - will do another test setup once this is out of the way and include Bedrock. Trellis a step to far right now. Thanks.
When those deprecation errors originate from the theme source, you can also easily selectively or completely disable them:
1 Like
Yeah - figured that but hadnāt started down that path yet. Those sources are super helpful - big thanks!
@ strarsis Sorry for the delayed response. Linting resolved itself. I discovered a random different issue, where images are getting hashed, bit not linking. An example of this is I have a hero background image on top of a gradient. Any ideas of how to link to hashed image on production build/
Just discovered that the Soil plugin (4.0.5) doesnāt seem to be working with 9.1. Works fine with Sage 10. Using Local by Flywheel running Apache with PHP 7.4.1 and MySQL 5.7.28 and WordPress 5.8 - any clues/suggestions??
The soil plugin has to be enabled by theme features.
However, this is the case for Sage 9 (and the update branch), too:
What exactly isnāt working? Plugin activation or runtime error? Are parts of the HTML not cleaned up?
Hi @strarsis - yep, plugin installed and activated and features enabled in setup.php. HTML isnāt cleaned up and nice search not activated. Has worked on previous instals with same process. Only noticed when I tried to pass in analytics via Soil.
Just tried a fresh install of 9.1 and same problem.
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 https://roots.io/plugins/soil/
*/
add_theme_support('soil-clean-up');
add_theme_support('soil-jquery-cdn');
add_theme_support('soil-nav-walker');
add_theme_support('soil-nice-search');
add_theme_support('soil-relative-urls');
/**
* Enable features from Soil when plugin is activated
* for Soil 4.x
* @link https://roots.io/plugins/soil/
*/
add_theme_support('soil', [
'clean-up',
'disable-rest-api',
'disable-asset-versioning',
'disable-trackbacks',
// 'google-analytics' => 'UA-XXXXX-Y', // @TODO: Add Google Analytics site key
'js-to-footer',
'nav-walker',
'nice-search',
'relative-urls',
]);
1 Like
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:
- A legacy Sage 9.x-based project that doesnāt build anymore because of dependency rot/node incompatibilities.
- Being very familiar with Sage 9.x and webpack. Sage 10 uses
laravel-mixthat 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.
4 Likes