Fix vls initialize is slow

[yoyo930021]

Fixed #2453

[rchl]

I'm seeing multiple instances of [INFO ] Loaded typescript@4.0.5 from /Users/... during initialize.

It's not only loading typescript from the root of the node_modules but also within the dependencies if those include typescript.

I know that dependencies should generally not include typescript in dependencies but I have a couple of packages linked. But in any case, linked or not, should this be optimized to only try to load from the root of node_modules?

EDIT: Actually "only from root" would probably be wrong as packages can have some @namespace/* in the name. So then should vetur only look at dependencies that are explicitly included in dependencies and devDependencies?

[yoyo930021]

I'm seeing multiple instances of [INFO ] Loaded typescript@4.0.5 from /Users/... during initialize.

It's not only loading typescript from the root of the node_modules but also within the dependencies if those include typescript.

I know that dependencies should generally not include typescript in dependencies but I have a couple of packages linked. But in any case, linked or not, should this be optimized to only try to load from the root of node_modules?

This code was prepared for monorepo.
People should be able to use different versions of TypeScript in their projects.
Although the TypeScript ecosystem doesn't seem to allow it.

[rchl]

With the monorepo setup, the intention is that each sub-project will have its own package.json, right? So my suggestion should still be OK.

And it's not only about typescript. Other dependencies like prettier will also be searched and discovered in some deep sub-dependencies.

[yoyo930021]

With the monorepo setup, the intention is that each sub-project will have its own package.json, right? So my suggestion should still be OK.

And it's not only about typescript. Other dependencies like prettier will also be searched and discovered in some deep sub-dependencies.

Your suggestion is good.
But this logic was prepared for the other libraries that came before it.

vetur/server/src/utils/prettier/requirePkg.ts

Line 17 in f37b984

const result = readPkgUp.sync({ cwd: fspath, normalize: false });

The main thing is that I want to be as consistent as possible with the require behavior.

[rchl]

But require wouldn't find dependency c located at node_modules/a/node_modules/c unless it would be called from node_modules/a/index.js, for example. So I'm not sure how current behavior is equivalent to require.

Note that I might not be seeing the whole picture...

[yoyo930021]

But require wouldn't find dependency c located at node_modules/a/node_modules/c unless it would be called from node_modules/a/index.js, for example. So I'm not sure how current behavior is equivalent to require.

Note that I might not be seeing the whole picture...

You're right.

[yoyo930021]

@rchl Thanks a lot.
Can you help me test your project for this branch?

[rchl]

Looks good with the latest changes. It didn't find any extraneous typescript dependencies (only the single, expected one) or any other dependencies. And it was relatively fast (~2s for initialize response).