Primitives for supporting ember-loose mode (.ts + .hbs)

[machty]

Starts in on support for ember-loose mode, the classic Ember component authoring format when you provide (optional) backing .ts/.js class with a separate .hbs template file.

Learnings / Takeways:

TL;DR, we can't follow support loose mode until we finish migrating to TS Plugin. Next steps are to find out how much of a lift that'll be.

• Volar only recently added support for two-file templating system (initially added for Angular-Webstorm; Angular has .ts files with .html template files)
• Volar's support only applies to TS Plugins, and does not currently offer support for two files in the (quickly-becoming-legacy) Language Server APIs
  • This means Glint will need to convert to using TS Plugin before we can support this
  • Alternatively Johnson from Volar might possibly be convinced to add support to the LS, but I think if we can get TS Plugin working, better to align with the future.
• Basic Volar scheme for two-file component systems:
  • In order to typecheck an .hbs file, you need to regard the backing .ts file as Volar's "entrypoint", in that you need to provide a VirtualCode for .ts files and teach those files how to find the "associated" .hbs template file. If you correctly/successfully do that, then when you attempt to typecheck the .hbs file, Volar will already know that it has been associated with the .ts file that it'll use as part of the transformation.
    • Note this doesn't cover the case of standalone .hbs files, which Ember classically supports
      • It is TBD whether we'll try to support this vs some other (hopefully scriptable) migration method, but if we do:
      • We would probably have to implement another HandlebarsVirtualCode and rely on Volar's internal algorithm to use the TS+associated HBS transformation/type-checking algorithm to "win" over the fallback HandlebarsVirtualCode used for standalone templates.

[machty]

This test is failing for strange reasons, but might be specific to CLI tests, so not focusing on it for now. Root cause seems to be that the ember component .ts file is not ever getting passed to createVirtualCode the language plugin.