l3ops

> do we plan to set a publishing workflow of this packages in another PR? The publishing workflow is already included in this PR, the `release_cli` workflow automatically publishes all...

> > The publishing workflow is already included in this PR, the `release_cli` workflow automatically publishes all packages under the `npm` directory so I simply extended it to also build...

> Hi @IWANABETHATGUY , could you please update the description and explain what's this umbrella for? I think we may "refactor" this umbrella to track both issues that are introduced...

> Should we limit this to only one read reference? Because if the "initializer" has side effects, we will be changing the code semantic. I think for refactors we can...

> While this is true, there's also the fact that we can't preview a refactor. It's my understanding that, as for today, these refactors are available only via LSP? Yes...

> @leops which binary and what's the command to start Rome in the LSP mode? Currently the binary that needs to be spawned is `rome_bin` with the argument `__print_socket`, but...

For now I would probably keep all of this in `xtask` (which is already interfacing with git in `codegen`) at least until we have something solid enough that would justify...

> @leops how did you add the Prettier tests? Do you have that script still somewhere with some instructions on how to run it? The script I used is committed...

I went through the SPIR-V specification and the GLSL 450 instruction set, and this is the list of node I came up with: - [x] Input - [x] Uniform -...

I would indeed be interested by design ideas since you seem to be referring to the DSL, and I haven't really got there yet, the representation I was talking about...