-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support resolving Stylelint using PnP #272
Comments
Hey Adaline! In general the main thing that requires the SDK is the bootstrap. Since packages are stored within zip archives, and since the resolution for the package's dependencies (here stylelint) is controlled by Yarn, we need the runtime to know what to do when accessing the files or resolving dependencies. Within To address that, the files pointed by the SDK mostly just need to make sure that our loader is properly setup before shelling out to the "real" dependency. For instance, this is all the SDK file for ESLint does. First it requires the So to get a "native" PnP support, you'd need to do the same thing by checking if there's a PnP file available (probably by checking the workspace root) and, if so, requiring it and calling its |
Thanks for the guidance! A few clarifying questions:
|
I've pushed up a PR (#273) that introduces built-in support, pending our discussion to make sure we're doing what we need to be so that we do this right. The relevant lines that actually do the resolution are: https://github.com/stylelint/vscode-stylelint/pull/273/files#diff-8fd5fc572876748046180731f3d1a4539c274424e9f34b386d14d33585f602c2R61-R125 |
Just calling our
It's likely we'll always generate the
It's a little unclear; VSCode Workspaces bring quite a bit of edge cases, and since we don't use them much in our team they aren't dogfooded as the rest of the integration. In theory you only need one runtime, no matter which one, which will then route the resolution to the proper resolution tables. In practice, the more complexity there is the higher is the chance for something unforeseen to happen... |
Fantastic! That makes everything so much easier.
I've added support for
Noted. Either way, sounds like our implementation wouldn't be any different in this regard from the editor SDK as the PnP runtime injection is still effectively happening in the same context, just in slightly different places. We'll just have to keep our eyes peeled in case we ever bump into anything weird. If that ever happens and it seems it may have more to do with Yarn or PnP than it does specifically with our extension, I'll loop you into it. |
Built-in PnP support has been merged and will be released in 1.1! |
PnP support released in v1.1.0! Is there any follow-up we need to take a look at, e.g. updating Yarn docs? |
Yarn 2.x and higher introduces PnP support, which is enabled by default. However, this extension does not support PnP, which is why Yarn's SDK tooling patches in a custom
stylelintPath
to allow Stylelint installed using PnP to be resolved. It would be great if we could have PnP work out-of-the-box without any additional configuration.@arcanis I'd appreciate your input if you have the time to share what might be a good next step!
The text was updated successfully, but these errors were encountered: