refactor: reorganize TS compiler

[bartlomieju]

Yet another refactor of TS compiler:

• made bundle() a standalone function instead of method of TsCompiler
• TS compiler doesn't depend on TextEncoder/TextDecoder
• removed dead code from TS compiler
• fixed typos

Fixes #5507

[kitsonk]

LGTM so far... let me know if you want/need anything

[bartlomieju]

LGTM so far... let me know if you want/need anything

@kitsonk I want TS worker to not use any console logs - so I want to move processConfigureResponse to Rust; can you look into that?

EDIT: commonPath and normalizeUrl also look shady... If we can remove them/move logic into Rust

[kitsonk]

processConfigureResponse

That is going to be hard-ish because it relies on ts APIs to ensure that stuff can be parsed, and it supports JSONC, and serde specifically refuses to support JSONC. I will have to look at swc and see if they support parsing of tsconfig.json files easily enough. Will look into it.

EDIT: commonPath and normalizeUrl also look shady... If we can remove them/move logic into Rust

They aren't shady! :-) I am not too sure we want to move them, because they are tightly coupled to how TypeScript generates the bundle (as in you have to "guess" at what the module specifiers are going to be because of this: microsoft/TypeScript#35052). They should go when we move the bundle generation out to Rust (as in all we do is take the single outfile and do the munging in Rust) which doesn't seem like we are ready to do that quite yet.

[bartlomieju]

processConfigureResponse

That is going to be hard-ish because it relies on ts APIs to ensure that stuff can be parsed, and it supports JSONC, and serde specifically refuses to support JSONC. I will have to look at swc and see if they support parsing of tsconfig.json files easily enough. Will look into it.

dprint supports parsing of JSONC dprint/dprint@ce9b5a6 - maybe @dsherret can expose parser?

EDIT: commonPath and normalizeUrl also look shady... If we can remove them/move logic into Rust

They aren't shady! :-) I am not too sure we want to move them, because they are tightly coupled to how TypeScript generates the bundle (as in you have to "guess" at what the module specifiers are going to be because of this: microsoft/TypeScript#35052).

I see, thanks for explanation I couldn't really grok what they are for.

They should go when we move the bundle generation out to Rust (as in all we do is take the single outfile and do the munging in Rust) which doesn't seem like we are ready to do that quite yet.

How would it take? I already do some munching on source maps generated during runtime code compilation so that shouldn't be a big deal.

[dsherret]

@bartlomieju the JSONC parser is here: https://github.com/dprint/jsonc-parser

I just recently added the parse_to_value function that you could use here.

https://docs.rs/jsonc-parser/0.7.0/jsonc_parser/fn.parse_to_value.html

[kitsonk]

I broke out the other two things into #5606 and #5607 so I could explain a bit more what is going on or needs to go on in my opinion as well as make sure it doesn't get lost. small bites

[bartlomieju]

@ry let's land this PR for 1.0.1

[ry]

Yikes.

[bartlomieju]

Those are all private interfaces not visible to end users

[ry]

LGTM - nice clean up