vscode-stylelint: [Bug]: Extention is not able to locate stylelint package

Glad to hear it’s working. Closing this issue now. Thanks for all the help with this!

Since you mentioned Windows, I thought I’d add mention I am also running macOS. Could be related.

For me VSCode is running on the host. I was trying to run stylelint 14 with a node_modules that is maintained by npm inside a Ubuntu 20.04 container. The project’s root folder is just mapped to /var/www/html, served by Apache.

From VSCode standpoint I think it doesn’t matter since it sees all the files on the host OS, so may be irrelevant.

To summarize for me the issue is that running stylelint 14 via CLI was working, but in VSCode it wouldn’t lint anything, and it wouldn’t give me any errors or startup so I can’t really tell why it wasn’t active.

I finally found some time to try your latest patch and got the same error as @chalkygames123. [Debug - 9:24:33 a.m.] [language-server] Failed to resolve Stylelint from global or workspace node_modules. | error: {}

Agh! The error object as logged is empty, so there’s no way to know exactly what went wrong, even though there’s definitely something happening there. It looks like the logger wasn’t properly serializing error objects, so certain information was missing when logged. I fixed this in #310, and a patched VSIX is below that contains this fix.

vscode-stylelint-1.0.3-error-serialization-patch.zip

So a little background on where my files live. Installing is done via yarn in WSL.

Project root / workspace
├── bunch of random files for initializing my PHP project
└── web
    ├── app
    │   └──themes
    │          └── WordPress theme folder
    │                  ├── node_modules  (containing stylelint)
    │                  ├── package.json
    │                  └── .stylelintrc
    ├── wp-config.php
    ├── index.php
    └── wp

I know its probably a very specific setup but hopefully you can help. Meanwhile I’m going to try out to remote into WSL via the WSL extention and see how that works in my day to day work.

I’m guessing the CSS you’re trying to lint is in your theme folder or deeper? In theory, so long as the extension is properly installed in WSL, it should work. Even if the package is installed in a subdirectory (or further out of the project), it should be able to be resolved.

I’m running Windows 11 with Fedora 35 running in WSL 2, with Node installed using Volta. I decided to see if I could repro the resolution error. I created the following file structure:

Workspace root
└── subfolder
    ├── node_modules
    ├── package.json
    ├── stylelint.config.js
    └── test.css

And it seems to work:

@chalkygames123 It looks like the error you and @Levdbas are experiencing are different, otherwise, the error that you both see would be the same. Could you copy your comment into a new issue so that we can track it as a separate bug?

Thanks to both of you for your patience with this. I want to get this working for you and whoever else may also be encountering the same issues. Your help debugging this is incredibly valuable. Without it, it would be so much harder to try and figure out what’s gone wrong and how to fix it.

Got it, this is it 🙂 The logs (with NODE_ENV=development) when the problem occurred (patched)

[Debug - 2:36:35 p.m.] [language-server] Failed to resolve Stylelint from global or workspace node_modules. | error: {"errno":-2,"code":"ENOENT","syscall":"spawn npm","path":"npm","spawnargs":["config","get","prefix"]}

@chalkygames123 Aha! This is the key line: it looks like when you start VS Code outside of the terminal, the extension’s attempt to run npm to find out where npm’s global node_modules is fails as the OS reports that there’s no command available named npm. I’ll do some investigating on my Mac to see what might need changing to let this work.

Does the extension account for node_modules not at the root of the project? (since as I understand, it no longer bundles stylelint, and looks for it in the “open workspace”.)

@fabd The resolution logic is as follows; any reference to a setting is a reference to the extension’s settings in VS Code, not Stylelint’s configuration file.

1. If stylelintPath is configured, try to require the module it points to.

   If the path is relative, the workspace folder, if one is available, is used as the directory that the path is relative to. Otherwise, the path is used as-is.

   If stylelintPath is not provided, this is skipped.

2. Get the global node_modules path for the package manager indicated by the packageManager option, which defaults to npm if not specified.

   This is done by calling the package manager with the correct command for it to spit out its global package installation path. For npm, this is npm config get prefix, for yarn, yarn global dir --json, and for pnpm, pnpm root -g.

3. Determine the current working directory from which to resolve modules.

   If the document being linted has a corresponding filesystem path, the document’s path is used. Otherwise, the workspace folder is used.

4. Try to require the module using vscode-languageserver’s Files.resolve.

   Files.resolve tries to get the package path using Node’s module resolution logic. The global package path is used to fill out NODE_PATH, which is used for global package resolution. The working directory, as provided, is used for the directory in which the require would be taking place.

In any of these cases, Stylelint is only considered resolved if the resolved module has an exported lint function.

So specifically in regard to your question, it should, in theory, be resolving the Stylelint package using the path of the document that the extension is attempting to lint as a starting point. So, at least if everything is working as it should, the extension should be able to resolve the Stylelint package even if it is not directly in the workspace root, whether it is deeper into the workspace or outside of it.

If you are experiencing issues with resolution, I suggest running Code with NODE_ENV set to development, which will tell the extension to emit debug logs. Then you can inspect the logs to see what’s going wrong. If you don’t see any details other than Failed to load Stylelint either globally or from the current workspace. without any errors or other details, try the patch mentioned earlier.

Thank you for your effort to get this resolved @adalinesimonian , much appreciated! I never encountered a maintainer so involved as you. 😃

Haha, well, I had to take some time away from work for health reasons, so I’m currently unemployed, hence why I’ve got all this time to work on this extension. Otherwise, who knows if I’d have the time, most open-source work is volunteered as you know. Luckily, I’m much better now, so I’ve been trying to nab a part-time job so that I still have time to volunteer with Stylelint. But, boy is it hard to find part-time tech work, almost everything’s full-time. Anyway, enough about that!

I uninstalled the regular version and installed the vsix patched version but no luck. It doesn’t give any more information then before. See: log2 with patch.log

I just noticed that your package manager configuration is set to Yarn. Are you using PnP in your project? If so, are you using the vscode-stylelint SDK?

#logError calls the very same logger used elsewhere in the resolver, so it’s strange that you’re not seeing any logs. It does have a condition that the connection be defined — and I can’t think of a case where you wouldn’t have one, both places in the code that instantiate a StylelintResolver instance pass to it a connection. But maybe that’s exactly what’s going wrong here.

Here’s a version of the extension with the patch from #294, which should coax out any logs that we may not be getting. If it doesn’t, then there’s some kind of error or issue happening wherein the inner resolvers don’t get a chance to execute, or throw, or perhaps some kind of unhandled promise rejection… all sorts of fun stuff.

vscode-stylelint-1.0.3-logger-patch.zip