feat: transition to @lwc/metadata for LWC JS introspection

[divmain]

What does this PR do?

This PR removes the lwc-language-server dependency on an ancient version of the LWC compiler. Now, @lwc/metadata is leveraged to provide intelligence on LWC JavaScript in the IDE.

Initially, the plan was to entirely swap out the data structures underlying a lot of the logic in the language server. Instead of relying on the very old Metadata type, all logic would be updated to instead rely on new metadata types exposed by @lwc/metadata. However, the changes necessary to make this clean swap proved to be extremely invasive. Continuing down that path would have required a de facto rewrite, with all the inevitable subtle incompatibilities and bugs that come with such an endeavor.

As an alternative, we chose to provide a mapping of @lwc/metadata to the old metadata data structure, including all of its idiosyncrasies. This approach comes with some benefits:

• the pre-existing behavior is reproduced ~exactly (or as close as we could come to it)
• further iterations and refactors can leverage new LWC metadata without disrupting existing functionality
• existing tests could be leveraged, adding confidence that this PR includes only non-breaking changes
• it should allow lwc-language-server to stay up-to-date with future releases of LWC, with the possibility that small changes to the mapping might be rarely required

As a follow-up I'll work to configure our CI to run your test suite whenever we update @lwc/metadata. If successful, the LWC team will be alerted whenever we make breaking changes to your code. In such an event, we would either 1) avoid the break or 2) proactively inform you of the change.

What issues does this PR fix or reference?

@W-13045347@

[salesforce-cla]

Thanks for the contribution! Before we can merge this, we need @divmain to sign the Salesforce Inc. Contributor License Agreement.

[divmain]

This monorepo has a top-level yarn.lock that conflicted with this package-local package-lock.json. Since the sibling packages do not have their own package-lock.json, I discerned that its existence here was probably unintentional.

[divmain]

Some compilation errors will only appear upon an attempted compilation. These are generally restricted to non-syntax errors, such as the fact that boolean public properties cannot be true by default (otherwise, how would the parent component disable the flag?).

So, we transform first using the up-to-date compiler to ensure no compilation issues exist. If it succeeds, we collect metadata about the component in the code below.

[CristiCanizales]

This looks good to me 🙂 And I know all the hard work to get to this 🥳
I also tested the usual features were working as expected, like:

• go to definition (html) ✅
• go to definition (javascript) ✅
• autocompletion ✅
• info on hover ✅

So I would say 🚢