Refrain creating ember-loose virtual code in non ember-loose environment

[mogstad]

I didn’t find a great place to test this, so ended up adding to the vscode test suite. Any better suggestions are very welcome.
Closes #846

[NullVoxPopuli]

lgtm

[machty]

This .only() needs to be removed so that other tests run. Normally vitest catches this on CI but these VSCode tests I think use mocha or something that doesn't catch cases like these.

[NullVoxPopuli]

Bah. I missed this :(

[machty]

Fix here #852

[mogstad]

Ah sorry!

[machty]

Nice, I can see some perf gains here; I wanted to guard for this originally but with some of the trickiness in TS Plugin's synchronous API it wasn't clear that we'd be able to synchronously determine the presence of ember-loose. Glad you were able to bring it back.

[machty]

FWIW I think there might be further potential perf gains here, because even with your PR, apps with ember-loose are still going to be parsing EVERY .ts file into the Loose VirtualCode upon the possibility that it contains a classic loose mode Component definition, i.e. even a file containing an Ember Data / WarpDrive model is going to be parsed into VirtualCode.

Part of the reason I did it this way was 1. just to get something working and 2. based on angular-webstorm's experience. With angular (pardon me bc I could be getting something wrong), a .ts file is considered a component once the @Component decorator is introduced, which might seem like an obvious / easy thing to detect to determine whether to parse into VirtualCode, but I think they opted to just parse ALL .ts into VirtualCode because, unless you do, with the way Volar works, Volar wouldn't be able to detect that a .ts file that previously didn't have a @Component should suddenly then be parsed into VirtualCode once @Component is added.

That said angular-webstorm might have additional perf checks to do a light-weight parse within the VirtualCode if no @Component is detected.

In our case, perhaps it's feasible to check whether a .ts file has /components/ in its path? Are there any cases of classic loose mode components being defined in, say, a src/ directory but not specifically in a components/ directory?

[NullVoxPopuli]

In v2 addons they can be anywhere. But default paths are /components/

Its worth the perf. Maybe we can add an option to add more component paths in TSconfig if needed

[machty]

Summarizing some of our discussions in DM:

The only potential downside/uncovered case by this perf improvement would be that we can't support the use case of v2 addons that still use loose mode components AND their components don't have a components/ folder in their folder ancestry. In such a case the addon authors wouldn't see type-checking diagnostics in their .hbs files. This is pretty tiny corner case seeing as how most folk on v2 have probably converted to .gts, and if not it's easy to have them move their components into components/ (or keep them there if they're already there) if they want the Glint 2 experience.