Assuming that your template uses the same conventions as the default core templates then your imports are wrong

@import "../../../media/vendor/bootstrap/scss/functions";

should be

BTW you should opt in you template to the new inheritable mode (eg move all the static assets to media/templates/admin/templateName, it's very easy: dgrammatiko/sloth@b5b4989)

Imports are already correct and the template's own build script works perfect fine.
The main difference with mine is that I compile data as opposed to actual files, and the imports work different when working with data.

node-sass handled this well but dart is a bit iffy when resolving paths.

Out of all honesty, Joomla's build scripts should not touch custom templates at all. If I run my build script with bespoke args, and then run Joomla's, it could alter the output CSS or simply break.

Out of all honesty, Joomla's build scripts should not touch custom templates at all.

If you Just correct the paths in your scss files then the Joomla's own tools should work fine. But I think that you should have a repo with your own template and then symlink the files to an actual Joomla installation (btw this is common practice for all devs afaik) if you want to do things in your own way. You can't have both ways working simultaneously without cannibalising one of them...

BTW the simplest solution is to rename your scss folder to scssSrc (or whatever different than scss) as this is the convention the core is using for the scss files...

If you Just correct the paths in your scss files then the Joomla's own tools should work fine

The imports are already correct and working

Nevermind, will do another workaround...

The imports are already correct and working

FWIW your imports are not correct as indicated in the error message:

Error: Can't find stylesheet to import.
@import "../../../media/vendor/bootstrap/scss/functions";

The reason is an administrator template scss file (inside a scss folder in that template) is 4 levels down from the root and you are going only 3 levels up. Maybe your build script is doing things differently but the references there are wrong

Maybe, the build scripts for the CMS should only take care of the CMS templates. And not all possible templates found. That's what I would expect and I think also what C-Lodder expects.

It's ridiculous to tell template developers to adjust their build tooling so the CMS one still works.

It's ridiculous to tell template developers to adjust their build tooling so the CMS one still works.

Sorry, I disagree, most devs already symlink their code to a live Joomla installation which will not matter what the Joomla tools are doing. If you want to develop on top of Joomla (it's really a very bad idea to inject your repo in the Joomla repo) then you have to respect the existing tools (of the Joomla repo) I already gave some extremely easy solutions here. But what Charlie was asking is kinda too much (keep the Joomla's conventions but not use the Joomla's tools)

My 2c

What I'm asking is for Joomla to target its own templates, like it used to, rather than the entire directory.

What I'm asking is for Joomla to target its own templates, like it used to, rather than the entire directory.

I know, basically you call for a revert of #31221

I guess this needs to be solved. There were people asking for a way to use the Joomla's own tools for their own templates, thus I did the PR in the first place. Do I care? No, but for most people with very little knowledge of Node and JS asking them to build SCSS templates without any tools (and probably without the knowledge to create such tools) this might backfire on the project.

In sort, Charlie, me and any other, well educated on js, devs could find a way around but poor PHP people will have a hard time putting together a tool to compile scss files. Therefore, with that in mind, I think the Project should provide these tools for all templates in the repo (once again the proper way of developing is by symlink-ing the own repo files to a Joomla installation, not coding on top of the Joomla repo).

That PR indeed is wrong as it is. It should be an optional behavior where the default only takes care of core templates.
Even better a parameter where you can specifiy which template it should process.

And we seriously should stop telling 3rd parties how they have to set up their dev enviroment. That's arrogant.
Yes, symlinking may be best-practice. But there are various reasons why someone doesn't do it like that and it works well for them. There is no reason to tell them to do otherwise.

That PR indeed is wrong as it is.

No it's not. The tools were adjusted to take care of ANY template because people asked for that (personally I have my own set of tools and since I'm symlink-ing my code I care less for what's in the repo).

And we seriously should stop telling 3rd parties how they have to set up their dev enviroment. That's arrogant.

Sure, but if the best practice is symlinking then why the heck am I arrogant to suggest someone to follow the best practices? I didn't proposed them to follow my own clanky thing but anyhow I also proposed another solution (rename the scss folder) which will also work fine in that context. So how the heck am I the arrogant again?

Anyways please test: #31853

I didn't say you were arrogant. I used "we" as a project because our tools currently basically mandate it.

our tools currently basically mandate it

Any tool makes some basic assumptions (or depend on some sort of convention) otherwise the cli command will be endless and nobody would ever be able to use it efficiently. What was buggy (my bad I guess) is that the tool didn't bail out for folders other than the ones chosen for the convention. The PR above should take care of that so everybody should be happy (eg want to use the built in tools then use the convention folder or use some other named folders and do whatever you want)