Sass plugin cannot resolve transitive npm package Sass imports in GitHub Actions runners

[frenchvandal]

Hi,

I ran into what looks like a Sass resolution issue when using Lume with Deno npm packages in a clean environment such as GitHub Actions.

Environment

• Lume 3.2.1
• Deno 2.7.5
• Dart Sass via lume/plugins/sass.ts
• GitHub Actions runner: macOS
• Sass dependency: @carbon/styles

Lume Sass configuration

import sass from "lume/plugins/sass.ts";

site.use(
  sass({
    options: {
      loadPaths: ["node_modules"],
    },
  }),
);

Sass entrypoint

My stylesheet imports Carbon Sass modules like this:

@use "@carbon/styles/scss/config" with (
  $prefix: "cds",
  $css--font-face: false,
  $css--body: false,
  $css--reset: false,
  $css--default-type: false,
);

Failure in clean environments

In a clean checkout, the build fails with:

Error: Can't find stylesheet to import.
   ╷
82 │ ┌ @forward '@carbon/grid/scss/config' hide $prefix,
83 │ │   $flex-grid-columns with (
84 │ │     $prefix: $prefix,
85 │ │     $flex-grid-columns: $flex-grid-columns
86 │ │   );
   │ └───^
   ╵
  @carbon/styles/scss/_config.scss 82:1
  src/styles/carbon/_config.scss 6:1
  src/styles/carbon/_theme-tokens.scss 12:1
  src/style.scss 12:1

What seems to be happening

• @carbon/styles is resolvable from top-level node_modules
• but its transitive Sass dependency @carbon/grid is not always materialized by Deno in a location that Dart Sass can resolve from loadPaths: ["node_modules"]
• in local development this can be masked if the workspace has already materialized more npm symlinks
• in CI or other fresh environments, it fails consistently

Current workaround

I was able to work around this by forcing Deno to materialize the Carbon package graph before the Sass plugin runs, by importing the relevant npm package.json files from TypeScript. After that, loadPaths: ["node_modules"] works again.

That workaround fixes the build, but it feels brittle and tied to Deno npm internals rather than something Lume users should rely on.

Questions

1. Is this a known limitation of the Lume Sass plugin with Deno npm packages?
2. Is there a recommended way for Lume to resolve transitive npm Sass imports in Deno projects?
3. Would it make sense for the Sass plugin to support a Deno-aware npm resolution mode, or at least document a canonical workaround?

If helpful, I can provide a minimal reproduction repository.

Thanks.

[oscarotero]

Ideally, the plugin should support npm specifiers (something like @use "npm:@carbon/styles") using Deno loader (like esbuild) or jsdelivr (like postcss/lightningcss). But SASS has a completely different module resolution, not compatible with anything else, so the implementation of this kind of automatic resolution seems complicated. That's why the SASS plugin requires the dependencies downloaded locally.

I guess your current workaround forces Deno to download the npm packages in the node_modules. So probably you don't need to do it manually and running deno install npm:@carbon/styles should be enough.

If you have a minimal reproduction, I can take a look. Maybe we can figure out a way to download automatically these dependencies.

[frenchvandal]

I received feedback from Deno Deploy Support (the same failure also occurs on GitHub Runners):

Thanks for sharing the build ID. We checked the logs for 4df6547hb3fa and can confirm the root cause:

The build failed because the Sass compiler couldn't resolve @carbon/grid/scss/config during the build step. Looking at the logs, the install step was effectively skipped (completed in under 1ms), so the npm dependencies like @carbon/grid weren't available when deno task build ran.

This aligns with the Lume issue you opened - it seems related to how dependencies are resolved in the Deno Deploy build environment vs. locally.

Glad to hear you have a workaround in place and that builds are succeeding now. We'll keep an eye on the Lume issue as well.

I will provide a minimal reproduction as soon as possible.

Thanks!

[folliehiyuki]

You can define a custom loader for SASS. I have this in my Lume site (requires raw-imports unstable feature):

  options: {
    importers: [{
      canonicalize(url) {
        if (
          url.startsWith("jsr:") || url.startsWith("npm:") ||
          url.startsWith("https://")
        ) {
          return new URL(url);
        }
        return null;
      },
      async load(canonicalUrl) {
        return {
          contents: await import(canonicalUrl.href, {
            with: { type: "text" },
          }).then((pkg) => pkg.default),
          syntax: "scss",
        };
      },
    }],
  },

The only downside is that it won't work with import aliases defined in deno.json config. You can tweak it to support all import strings with deno: prefix (so @use "deno:npm:<some_package>" instead of @use "npm:<some_package>" for example), if that use case is needed.

I don't know whether it works with transitive dependencies or not. For simple stuff (.e.g sass-extras NPM package) that I use, it's sufficient.