Conditionally use LWC type definitions

[wjhsf]

The language server currently copies type definitions from an old version of LWC. This was originally added to facilitate autocompletion in JavaScript projects. However, in modern VS Code, if a project has lwc in its node_modules, then autocompletion is provided out of the box. Any project that has unit tests for components will necessarily have a local copy of lwc, so copying the type definitions is unnecessary.

Additionally, for TypeScript projects, there are significant incompatibilities between the bundled version (v2.37.3) and the latest version (v8.0.0). For a project using the latest version, a user with the VS Code extension installed will need to have experimentalDecorators: true in their tsconfig.json, while a user with a different IDE will need to have experimentalDecorators: false. Since that is not possible, and to remove the need for the language server to keep up with LWC versions, the default behavior should change to using the locally installed version of LWC from a user's project.

[SCWells72]

Hi, @wjhsf. Thanks for directing me to this issue. You mentioned the following in your message that brought me here:

Longer term, the goal is to entirely replace the extension's types with the @salesforce/lightning-types npm package, which will work with any toolchain. We're currently working on populating the package (which will eventually have types for ~200 components/modules!). As we add type definitions that conflict with the extension's types, we will remove them from the extension.

In addition to the static type definitions, presumably the TypeScript transpiler also needs the dynamically-generated, project-specific ones, e.g., those that help fulfill imports for @AuraEnabled Apex symbols, SObject types and their fields, message channels, static resources and content assets, etc.

Right now those are generated by the VS Code Extensions into .sfdx/typings/lwc which is very much considered a working directory and not something that should be checked into version control or similar. That presents a challenge for third-party tooling such as other IDEs (I'm the developer of Illuminated Cloud) and automated tools such as CI/CD systems.

Is there also a plan to have the CLI deployment commands -- or something else -- generate those stubs before trying to run the TypeScript transpiler which itself would occur before trying to deploy the resulting LWC component with its *.js file(s)?

I'm just trying to wrap my head around where this is going. I've already implemented the editor aspects of LWC TypeScript support in Illuminated Cloud, but these issues with deployment of those components based on what I've described above has resulted in me backing out those changes until this aspect reaches a higher level of maturity. Please let me know if this isn't the right place to have that discussion and/or monitor progress on that work.

[wjhsf]

Right now those are generated by the VS Code Extensions into .sfdx/typings/lwc which is very much considered a working directory and not something that should be checked into version control or similar.

I'm not familiar with this area, but theoretically we could generate those types into a directory that could be committed. Assuming there aren't any data privacy concerns with the generated types, or anything like that.

Is there also a plan to have the CLI deployment commands -- or something else -- generate those stubs before trying to run the TypeScript transpiler which itself would occur before trying to deploy the resulting LWC component with its *.js file(s)?

Our goal is to have the TypeScript developer experience be as seamless as it is for JavaScript projects. Part of that is having as much feature parity as we can between the VS Code extension and the CLI. I haven't looked into generating stubs for custom objects at all, but it seems feasible that it could eventually be included in the CLI.

Please let me know if this isn't the right place to have that discussion and/or monitor progress on that work.

To get more details on the roadmap, and to provide feedback for things you'd like to see, please reach out to Clay Martin.