Transfer to ember-tooling

[evoactivity]

Since we're going to merge ELS and it's vscode extension to the org, we should probably transfer ownership of this over as well.

[lifeart]

@evoactivity good point
I think we need a space for experiments with syntax, and not bother existing users of this extension, we need to explore way to be able to keep existing extension in store and be able to publish official under ember tooling org...

Let's take some time and land LS first, and then figure out approach here (it may be a case that forking this repo into org may have more sense)

[evoactivity]

Yep, doesn't need to happen right away, I have some thoughts about changing how this is distributed anyway. Ideally bundling the grammars into the vscode-ember extension so most users will only need one extension to get all the language features.

I do think pre-releases would allow us to experiment without needing to maintain separate extensions, but we can discuss that approach at a later date.

[lifeart]

@evoactivity tbh I don't like a way to have builtin grammars, because it's completely disable ability to opt-out for end users.
VSCode has extension pack, and IMHO it's only one correct way to distribute default config, but with ability to replace/disable some parts for end-users.

If we have all-in-one case, we basically disabling field for experiments and produce stagnation in ecosystem. We should allow different parts to be changed or replaced and not try to create artificial coupling.

[lifeart]

In ideal world we should have Ember extension pack or Ember Polaris, with all necessary extensions, without trying to glue all in it.

[evoactivity]

Bundling syntax and language server would bring us inline with the broader js ecosystem and how other languages do it. The user expectation is that installing the extension for a framework or language installs everything they need in one package.
https://github.com/vuejs/language-tools/tree/master/extensions/vscode
https://github.com/sveltejs/language-tools/tree/master/packages/svelte-vscode
https://github.com/rust-lang/rust-analyzer/tree/master/editors/code
https://github.com/ziglang/vscode-zig
https://github.com/Microsoft/vscode-python
https://github.com/redhat-developer/vscode-java
https://github.com/golang/vscode-go

The extension pack does kind of do this, but we still end up with multiple extensions in the marketplace which leads to confusion and more things to maintain spread across many different repos with a number of different owners.

I'm not convinced we need separate extensions to enable experimentation. Is there a reason you see that pre-releases wouldn't work for that use case? People who want the experimental versions could install the pre-release of the extension and people who want the stable version would install the stable one.

[lifeart]

I'm not convinced we need separate extensions to enable experimentation. Is there a reason you see that pre-releases wouldn't work for that use case? People who want the experimental versions could install the pre-release of the extension and people who want the stable version would install the stable one.

• let's imagine an unlikely case of Ember ecosystem stagnation and feature freezing in ember-tooling org.
  if we have all-in-one extension, anybody who would like to experiment (improve) DX need to fork all-in-one and basically, duplicate core functionality, and maintain all-in-one fork. If smb prefer different color syntax, it has to fork extension including language server and deal with it, including LS updates.

The extension pack does kind of do this, but we still end up with multiple extensions in the marketplace which leads to confusion and more things to maintain spread across many different repos with a number of different owners. - extension pack do exactly with with builtin modularity and flexibility.

but we still end up with multiple extensions - there is no guarantee that it won't be case with all-in-one extension (try search for typescript).

Ember community may reference to official extension pack in VSCode documentation and be able to swap any of extensions once needed without rewriting docs.

[evoactivity]

anybody who would like to experiment (improve) DX need to fork all-in-one and basically, duplicate core functionality, and maintain all-in-one fork. If smb prefer different color syntax, it has to fork extension including language server and deal with it, including LS updates.

That's a good point

but we still end up with multiple extensions - there is no guarantee that it won't be case with all-in-one extension (try search for typescript).

True.

I'll put a pin in this for now, we can continue talking about having an official version once we get other tasks done.

[lifeart]

As one of the options for transfer:

1.) We creating repo with same name in ember-tooling
2.) I'm changing base and pushing all content of this repo to ember-tooling
3.) I'm removing this repo
4.) I'm forking ember-tooling version to here (this repo name) (likely need verification that github allow it after repo removal)
5.) We are good, this extension still may be published, source will be in ember-tooling, history is preserved

• this flow require secrets update, because it would be lost after removal