Able to use with alternative toolchain (without babel)

[Jack-Works]

Describe the enhancement

I'd like to contribute support for the TypeScript toolchain (without babel dependencies).

I found in @linaria/webpack4-loader, @linaria/webpack5-loader and @linaria/rollup.

Motivation

Let people be able to use linaria without babel.

Proposed changes (Roadmap?)

1. Introduce jest-file-snapshot and let test cases become a folder on their own (so it can be shared the test with TypeScript).
2. @linaria/webpack4-loader, @linaria/webpack5-loader and @linaria/rollup should not depend on @linaria/babel-preset directly.
   Possible solution 1: Transformers should be applied in their own loaders/plugins (e.g. babel-loader or ts-loader) instead of re-parsed and re-transformed in @linaria/webpack4-loader, @linaria/webpack5-loader and @linaria/rollup. Linaria depends on some extra metadata to generate CSS files. That info can be added (in the transformer) as a comment in the source file (e.g. // @linaria: <metadata JSON here>) and get collected in the loaders so the loader does not need to call the babel.transform directly.
   Possible solution 2: The transform implementation should be passed explicitly.
   Pros of solution 1: No need to parse the code twice. People can configure things separately (add linaria transformer in babel-loader).
   Cons of solution 1: Need to use a hack way to store the metadata.
   Pros of solution 2: No need to change the architecture too much.
   Cons of solution 2: Still need to parse the code twice.
3. Implement babel transformer in TypeScript transformer (without evaluator/cross-file knowledge).
4. Implement the evaluator in TypeScript toolchain.

Related Issues

#197

[Jack-Works]

I think the evaluator part is the most difficult part 😢. It seems like this part is a partial evaluator that performs so much analysis.

[Anber]

the evaluator part is the most difficult part

Yep. It is.
The tricky part is that we aren't able to analyze all JS/ES/TS features so that I've implemented a dirty hack with transpilation to es5 before shaking. ES5 is pretty simple to analyze but it's still a big bunch of babel-related code. In theory, we can replace almost all logic of shaker with some tree-shaking library like terser. It will dramatically reduce the complexity of shaker itself. However, shaker also builds a cross-file dependency tree, which is required on eval stage, and that work should have been done even if terser does all shaking-work. Webpack and rollup have this dependency tree, but it seems like we cannot get it.

[Anber]

I see two directions:

1. Replace complex logic in shaker with terser and some trees-shaker for TS.
2. Introduce some dependency tree builder, which will be much simpler and can be implemented around an abstraction over babel/ts AST.

Does typescript ecosystem have something like terser?

[Jack-Works]

Does typescript ecosystem have something like terser?

Hmm... No, I think terser is the only way to do this, I don't know if there is a tool in ts AST

[Jack-Works]

I'm sorry, after investigating this, I found it is much more challenging than I thought. The transformation part is easy for me to make but without the evaluator, it won't be much useful.
I cannot complete the evaluator part in a toolchain irrelated manner/re-implement this in the TypeScript toolchain.

I'd still like to provide a TS transformer if the evaluator part is resolved. I'm closing this issue at least for now.