Shorten CSS references for @import or @use

[hgiesel]

For our own references, we will only use the name as relative to /ts/sass, e.g. ts/sass/button-mixins becomes button-mixins.

For references to npm modules, we will use the path relative to node_modules, e.g. ts/sass/bootstrap/alert becomes bootstrap/scss/alert.

This will make it easier for an external user to use our Svelte components. They would need to link our sass library under /ts/sass in their includePaths, and any of the libraries we use internally (so far bootstrap and codemirror).

[dae]

I've fixed the spurious error, but that's revealed another. SASS_PATH in svelte.bzl:svelte_check() might need adjusting? I'll need to test this works in an external workspace too.

[hgiesel]

21b6696 contains what I thought might fix the issue, however it doesn't. I'm not quite sure why though. The runtime directory seems to contain all the necessary files.
Exporting //ts:sass from ts/BUILD.bazel and using that made the SCSS files resolve, but instead I got warnings that they shadow existing files.

[dae]

This seems to fix it, which implies it was not working previously:

diff --git a/ts/svelte/svelte.bzl b/ts/svelte/svelte.bzl
index 565ad518f..3c87a21d2 100644
--- a/ts/svelte/svelte.bzl
+++ b/ts/svelte/svelte.bzl
@@ -93,7 +93,7 @@ def svelte_check(name = "svelte_check", srcs = []):
             "//ts/lib",
             "@npm//sass",
         ] + srcs,
-        env = {"SASS_PATH": "$(rootpath //ts:tsconfig.json)/../sass"},
+        env = {"SASS_PATH": "ts/sass"},
         # a lack of sandboxing on Windows breaks the local svelte_check
         # tests, so we need to disable them on Windows for now
         target_compatible_with = select({

The build seems to work correctly on an external workspace, and while I suspect svelte_check won't, that's not a big concern. Please let me know when you've pushed the change and I'll run the test on Windows to confirm it's ok there, and then it should be ok to merge once we get another bugfix release out the door.

[hgiesel]

Fix pushed.

[dae]

Thanks, looks good on Windows too

[dae]

Aside from having less text to type, are there any advantages to this PR after #1340? Paths relative to the repo root (eg ts/...) are standard in Bazel, so we'd be moving a bit away from common practice by doing this.

[hgiesel]

When add-on devs use SCSS, they could reuse Ankis SCSS, which would be nice.

I've added a symlink anki in ts/sass which leads to ., this way add-on devs can use the SCSS like

@use 'anki/button-mixins' as button; 

Here's an example how I set up New Format Pack to use Ankis SCSS.

[dae]

Thanks, appreciate the example. I was initially concerned about API issues, but changes to our sass shouldn't affect already-built add-ons, so that seems like it could work.

[dae]

The symlink is causing a warning on all builds:

(11:19:25) ERROR: Infinite symlink expansion, for ts/sass/anki, skipping: Infinite symlink expansion

I'll remove it for now - can we accomplish the same thing a different way?

[hgiesel]

It's not really a big deal, as users can still reference our SCSS without the Anki prefix (which only becomes a problem, if there duplicate names), or recreate the symlinks themselves.
E.g. the add-on dev can create a scss/ directory himself, reference it in the includePaths, and put a symlink called anki in there that references the Anki sass/ directory.

As long as we don't publish an NPM module, the add-on dev will require an external reference, that will be machine dependent. Be it in the includePaths, or through a symlink in their project.