yarn@berry support.

[Sombian]

• I have searched through existing issues
• I have read through docs
• I have read FAQ

Info

• Platform: windows 10 x64 pro
• Vetur version: latest (0.23.0)
• VS Code version: latest

Problem

as you can see from the picture above, it warns user that module has not found (this also includes built-in) whilst its not.
never had this problem without yarn@berry.

Reproducible Case

on existing or freshly forged project, with yarn@berry either globally or scoped install,
run yarn install.
then in .vue files, try import any of modules (built-in or external, native (java|type)script works fine though)

[Qwertronix]

A way to have the VLS use the tsserver and tsc pointed at by the "typescript.tsdk" setting in vscode could provide at least a temporary solution to this until more indepth support for PnP can be implemented.

As a workaround in my current project I'm adding nodeLinker: node-modules to .yarnrc.yml, which disables PnP entirely and removes a lot of the benefits of yarn@berry.

[Sombian]

A way to have the VLS use the tsserver and tsc pointed at by the "typescript.tsdk" setting in vscode could provide at least a temporary solution to this until more indepth support for PnP can be implemented.

As a workaround in my current project I'm adding nodeLinker: node-modules to .yarnrc.yml, which disables PnP entirely and removes a lot of the benefits of yarn@berry.

then theres no point of using yarn@berry if i do so.
thanks for your suggest but id rather keep error as it wont cause error on script but workspace.

[octref]

I'm not sure what I can do to fix this. What does yarn@berry do different than yarn v1 to modules? Does TS support it?

[Seally]

Yarn v2 defaults to PnP (which is in v1 too, but not enabled by default), which basically means node_modules is gone (unless the node-modules linker is used) and module resolutions are now handled by the .pnp.js file generated at the project root. The installed modules themselves are generally stored in zip archives, which reside in <root>/.yarn/cache by default for Yarn v2. The .pnp.js file I believe also comes with the virtual file system needed to access stuff within the archives.

TypeScript currently doesn't natively support PnP, but v2 users get a patched version that does support PnP automatically upon installation. So for the TypeScript language server to work correctly, it needs to use the user-installed version while under PnP environments for now.

Basically, instead of assuming installed module files are stored under node_modules, in PnP environments we'll need to load the PnP API and access the modules using the patched resolver instead.

@arcanis I'd like to explain this in more detail, but I don't really know the internals that much. :/

[arcanis]

That's a good explanation 😃

A way to have the VLS use the tsserver and tsc pointed at by the "typescript.tsdk" setting in vscode could provide at least a temporary solution to this until more indepth support for PnP can be implemented.

I'm not familiar with Vetur, but this seems the best option to me if that's compatible with your architecture. Looking at #682, it seems this is already possible if the users configure vetur.useWorkspaceDependencies, is that correct?

[octref]

it seems this is already possible if the users configure vetur.useWorkspaceDependencies, is that correct?

That is correct and we use the workspace version of TS to resolve modules:

vetur/server/src/services/typescriptService/serviceHost.ts

Line 251 in 2ddd169

resolveModuleNames(moduleNames: string[], containingFile: string): (ts.ResolvedModule | undefined)[] {

[AlexandreBonaventure]

I've made a quick PR as a proof of concept, so everyone get the idea. This kind of implementation would work IMHO.
Please let me know how I can finalize this PR. Thanks

[AlexandreBonaventure]

This #1737 PR seems to be a good quick solution, I believe it is ready to review

[chriswoodle]

Any updates on this? Hoping to have intellisense working

[AlexandreBonaventure]

@chriswoodle if anything, as a workaround I compiled my own Vetur (on the above PR branch) and work with it for months already, works A-OK!

[octref]

Fixed in #1737.