using SASS @use "sass:meta" causes "issues" in bit status

[utillity]

Describe the bug

I have a styles.scss file in the root of my angular bit-app, which contains this in line 1:

@use "sass:meta";

bit status generates the following issue:

     > my.scope/web-app ...  issues found                                                                                                                                                                                                                                                              
       missing packages or links from node_modules to the source  (run "bit install --add-missing-deps" to fix both issues):
          src/styles.scss -> sass:meta

If I run bit install --add-missing-deps as suggested, of course there is no package sass/meta:

GET https://node-registry.bit.cloud/sass%3Ameta: Not Found - 404
sass:meta is not in the npm registry, or you have no permission to fetch it.
No authorization header was set for the request.

Steps to Reproduce

1. add an ng-app in your bit workspace with SASS support
2. add this to your scss file: @use "sass:meta";
3. run bit status

Expected Behavior

This sass command should not cause an issue in bit status

Specifications

• Bit version: (run bit -v) 1.10.0
• Platform: Windows 11
• Env: (if component-specific, run bit env and paste its environment) bitdev.angular/angular-env@8.2.4

[GiladShoham]

Thanks, we will fix it

[utillity]

thank you! that's the most pragmatic and solution-oriented answer I got in a while 😄

I guess any @use sass:* should be ignored (I assume bit can safely ignore any @use within scss files)

[davidfirst]

@utillity , I'm unable to reproduce. See screenshot attached.

In general, this is implemented. It knows to recognize such built-in modules. You can see this test as a reference:
https://bit.cloud/teambit/styling/deps-detectors/detective-sass/~code/detective-sass.spec.ts#l83

[utillity]

Hi @davidfirst I think it has been fixed in the mean time. I just haven't pulled the new version yet. Tilli

[rvnlord]

I would like to let you know that this issue is still happening, it is easy to reproduce with literally any React component.

Side question: Is there actually a way to programmatically control the dependency resolver through custom env (like one can control the build pipeline)?

[rvnlord]

To give you an update on this issue, I added a node-app project to my Bit workspace for testing, but then spent a significant amount of time trying to understand why my breakpoints wouldn't hit. The root cause was that the actual application runs from an unexpected location (unexpected to me, at least – it highlights a gap in my Bit knowledge!).

The working launch configuration is as follows:

{
    "type": "node",
    "request": "launch",
    "name": "ConsoleTest Node App",
    "program": "${workspaceFolder}/node_modules/@teambit/bit/dist/app.js",
    "args": [
        "run",
        "projects/commonlib/console-test",
    ],
    "restart": true,
    "console": "integratedTerminal",
    "internalConsoleOptions": "neverOpen",
    "cwd": "${workspaceFolder}",
    "sourceMaps": true,
    "outFiles": [
        "${workspaceFolder}/node_modules/.pnpm/**/node_modules/**/dist/**/*.js",
        "${workspaceFolder}/node_modules/.pnpm/**/dist/**/*.js",
        "${workspaceFolder}/node_modules/**/dist/**/*.js",
        "${workspaceFolder}/**/.bit/**/dist/**/*.js"
    ],
    "resolveSourceMapLocations": [
        "${workspaceFolder}/**"
    ],
    "skipFiles": [
        "<node_internals>/**"
    ]
},

For anyone else needing to figure this out, the method is to run the app with module debugging enabled. This command will log the module loading details to a file, which you can then search to find the actual execution path.

$env:NODE_DEBUG="module"
node node_modules/@teambit/bit/dist/app.js run projects/commonlib/console-test *> debug_output.txt

Is this debugging configuration documented somewhere (outFiles that Bit's node-app requires)? Or am I missing something that's considered common knowledge?

After finally getting the debugger to work, the real twist is that the code in question actually runs as intended... The original problem persists, however, as I'm still encountering an error when trying to use sass:map in my .scss files.

Despite the hurdles, I want to emphasize that I genuinely appreciate the technology. The issues are just part of the learning curve.

[davidfirst]

@rvnlord ,
I don't use the debugger much, but when I did, I don't remember adding $env:NODE_DEBUG="module". The vscode extension has a command to add the debug configuration, it might help.

As to the sass:map issue you're having, can you please provides steps to reproduce?
From the last screenshot you sent, it looks fine. You're testing whether it returns an empty array and it does, which is what I expected.
In fact, we have a similar unit test in teambit.styling/deps-detectors/detective-sass component:

  describe('use syntax with colon', () => {
    it('should return only the package name (the part before the colon)', () => {
      runTest('@use "pkg:math"', ['pkg']);
    });
    it('should return an empty array when it is a built-in module', () => {
      runTest('@use "sass:math"', []);
    });
  });

This test passes.