feat: Update Component Generator for Colocation

[Alonski]

No description provided.

[lifeart]

@Alonski trying this pr in my repo, I suppose ember g component name -ns should generate only template, but it's generating index,{hbs,ts} without @glimmer/component import.

[Alonski]

Thanks for testing @lifeart
This isn't really ready yet. I'm not sure if I'll keep working on it.

[lifeart]

@Alonski at least, I really need this blueprint for octane app demo xD.
I beleve there is the plans to add support for such functionality, but, I think it's possible to create minimal addon blueprint, like ember-octane-typescript-component and use this MR inside it (owerriding ember-cli-typescript-blueprints component, and adding component-class blueprints).

And once ts team will be ready, we can backport features to this repo or such.

Users already using ts and octane, and I think we have to provide an option to avoid manual boilerplating. And it's doesn't really matter where it's located.

[chriskrycho]

@Alonski this has obviously been sitting for way too long. We'd be happy to help you land it, at least as a stopgap while we iterate toward a new and better approach for blueprints. If you'd prefer we just close it, we can do that, too!

[lifeart]

@chriskrycho since now we have builtin way to enable typescript compilation (in ember-cli-babel), I wondering, could we move this blueprints into ember scope, to simplify maintance & upstreaming? (or use existing .js blueprints with some if's, related to .ts?

cc @Alonski

[chriskrycho]

Can't move it into Ember scope until we go through an RFC process to make TS support official. 😉 However, working from/with existing .js blueprints is indeed what we're aiming toward medium term.

[lifeart]

in my understanding, for mid-term period, it may be an fork of default ember templates, with patch after RFC will be merged? trying to figure out maintainable & easy to iterate approach