Unable to use @vscode/python-extension due to peerDependency on @types/vscode

[DonJayamanne]

In the Jupyter extension we do not directly add @types/vscode instead we use @vscode-dts which pulls down the necessary type definition files.
However this doesn't work well with the peerDependency in the @vscode/python-extension package.

The following command fails in npm npm list --production --parseable --depth=99999 --loglevel=error
I have used vscode-dts -f to remove the npm package installed by the Python extension as thats not required.

Suggestion: Use optionalDependency in favor of peerDependency,

Basically we're unable to use the Python extension when using the vscode package @vscode/dts https://github.com/microsoft/vscode-dts

[DonJayamanne]

My current work around is to remove the peer dependency upon installing the python npm package.

[brettcannon]

Why do you skip @types/vscode and instead download the .d.ts files using @vscode/dts? Is it for space savings or does [@types/vscode](https://www.npmjs.com/package/@types/vscode) not update fast enough for you?

And what are the ramifications of moving the dependency to optionalDependency? Looking at the npm install docs it looks like skipping the optional dependencies are an all-or-nothing thing, so you would have to skip the optional dependencies for every dependency you have?

[DonJayamanne]

Why do you skip @types/vscode and instead download the .d.ts files using @vscode/dts

@vscode/dts makes a lot of improvements in development (these are the improvements for Jupyter extension):

• Automatically pulls proposed.d.ts files bsed on contents in package.json
  • I.e. no need to manually add proposed.d.ts files for vscode api
• Proposed.d.ts files are not checked in, big bonus
  • We had a lot of problems in the past where the api would change and we wouldn't know as the type definition file was commited into the repo and that never changes.
  • This way we always pull the latest proposed and compilation fails immediately,
  • I.e. we catch updates to proposed API immediately, as opposed to waiting to ship the exetnsion into vscode and things the fall over during runtime
• @vscode/dts is a CLI tool, hence there's no manual component here to keep things updated
  • E.g. with @types/vscode we need to manually update that everytime we need to use new API, with @vscode/dts we always end up having the latest stable bits and laetst proposed API (only which ever is used in package.json file)

Note: We used to run into issues with the previous approach (some of the above drawbacks), and then migrated to @vscode/dts that solved them.

I'm sure there could be others, basically I would list improvements/reasons of why @vscode/dts was built in the first place (but the ones I listed as the main ones I can think of) and its benefits over @types/vscode.

r you? And what are the ramifications of moving the dependency to optionalDependency? L

All I want is to avoid having two packages that provide the same types.
thats the only problem i have, right now we get types using @vscode/dts and that sees a conflict in the node_modules form @types/vscode, and the only option is to pass the -f flag into the @vscode/dts CLI so that it removes them.

But that doesn't work when building using webpack.

My understanding of optional dependencies is that npm will attempt to install it, andd if it cannot then that's still fine. So in this case the @types/vscode package will still get installed with the optional dependency approach.
thus @vscode/DTS and webpacks benefits from this, as deleting it is the same as not installing it and it will not get flagged by webpack (which is what happens today).

This suggested approach allows one to use python extension npm and pull vscode types using either of the two approaches.

We use at least one optional dependency in Jupyter extension today.

[brettcannon]

All I want is to avoid having two packages that provide the same types.

I understand why you want this, but I'm trying to understand the ramifications for our users who are not in your situation and make sure they won't end up in a bad place by accident if we implement your idea and someone runs npm install --no-optional. My assumption is they will be fine since I would assume TypeScript just falls back to assuming no types are known about the JS code.

[DonJayamanne]

assumption is they will be fine since I would assume TypeScript just falls back to assuming no types are known about the JS code.

Yes, thats correct.

[karrtikr]

It still leads to conflicts due to double installation of vscode types when testing through the cases, removing vscode types as dependencies altogether and documenting to install it separately instead, similar to how WASM does it.