New project: Community-driven tsc with extra flags.

[cspotcode]

Replacement for TypeStrong/ts-node#770.

I have an idea for a new project that I think is a good TypeStrong candidate, and I'm hoping to solicit a second opinion.

tsc is very compelling as a straightforward CLI interface to the compiler. For example, one of my coworkers -- not a TypeScript developer -- was curious what it could do for his project, so he did npx typescript tsc --noEmit --allowJs --checkJs. CLIs are great for accessibility. The TypeScript team talks about this in their 2019 roadmap, under "command-line experiences." Some really cool compiler features aren't exposed by the CLI:

• Dump diagnostics -- including extra "related" info from --pretty -- as parse-able JSON
• Transpile without typechecking, for speed and/or for projects that are migrating from JS and will have type errors for a while. Or for development, where you want to run code even if it has type errors, and maybe ts-node isn't a good fit. As a transpiler, this is simpler to configure and runs faster than babel. (tsc-to) (someone else making the case: TypeScript "non-standard" compiler options #1 (comment))
• Log a list of quick-fixes matching a grep expression.
• Apply all quick-fixes that match a grep expression.
• Support transformers, like "ttypescript"?

I think the barrier to entry with a project like this, is there's no easy way (that I'm aware of) to do all the bootstrapping that tsc does. It discovers tsconfig, loads and parses "extend"ed tsconfigs, gets a list of source files, and creates a language service. Ideally there would be a single function call to: augment tsc with additional CLI flags to parse, perform the above tsconfig discovery, and get back a parsed config and a language service instance.

I suppose I'm proposing 2 projects:

• a) A bootstrapper that mimics tsc's bootstrapping, giving you a fully parsed tsconfig and a language service instance to do whatever you want.
• b) A tsc drop-in replacement with miscellaneous extra features, powered by (a).

Am I reinventing the wheel? Is this a good candidate for TypeStrong? Is there prior art I can build off?

EDIT: cleaned up a few sentences

[aciccarello]

Sounds interesting. I know that the typedoc project has tried to wrap tsc (with limited success). The Angular team also has their own wrapped ngc CLI.

I'm not sure how typescript adding plugins fits into this. Do plugins reduce the need for CLI wrappers?

[nycdotnet]

grunt-ts is a wrapper to tsc and also essentially has its own version of tsconfig parsing; it effectively does much of what you have proposed in "a", minus the language service. You could certainly crib some stuff from there. I think your idea is a good one.

TSC definitely has a handful of features that are not supported via tsconfig and vice versa. For example paths and rootDirs are only in tsconfig.json, and things like init and help only make sense in a tool like tsc.

I have been honestly wanting something like what you've described for a while for grunt-ts. Even for the scenario of, for example, implementing the equivalent of watch with tsc, but having pre- and post-hooks.

[cspotcode]

@aciccarello Language service plugins don't run within tsc, only within the language service. Plugins bring to mind a few more features a CLI alternative can offer:

• load plugins and include their diagnostics in the CLI output
• load plugins and show / apply their quick-fixes

@nycdotnet thanks, I'll take a look at the grunt-ts code.

Regarding features that are only supported in either tsconfig or tsc, I'd like this library to handle that as well.
Ideally it will accept one or more of:

• a filesystem abstraction (defaulting to using fs, generating the right Host)
• an argv array
• a cwd
• a "project" string, for programmatic cases where you don't have an argv array
• a compilerOptions instance, for programmatic cases where you don't have a tsconfig

And it will return:

• path to tsconfig(s)
• parsed tsconfig
• parsed tsc flags that can't go into tsconfig (--init, --build, --help, etc)
• list of matched source files *
• language service instance *

*Callers can request that these items are omitted for performance

We should eventually support discovering composite tsconfigs as well, but I'm not sure exactly how that should look.

[nycdotnet]

What are you referring to regarding “composite” tsconfig?

The code in grunt-ts could use a refactor or two but at least it’s covered with tests and it supports merging a tsconfig with the arguments from the Gruntfile (though some recent switches aren’t natively supported yet because I am lazy).

For a goof you might also want to check out csproj2ts which parses msbuild project files for TypeScript switches (though it has a rather poor implementation of the msbuild logic). Not sure if that would be useful to you except perhaps as more inspiration for parsing arguments or for some type definitions.

Good luck!

[cspotcode]

"Composite" refers to project references via "composite": true.

If a project is configured to use --build with a tsconfig.json, src/tsconfig.json, and tests/tsconfig.json, then third-party utilities may not understand this, so you'll have to special-case those tools. For example pushd src ; ts-documentation-generator ; popd

I think this is a low priority feature, but still worth considering.

[nycdotnet]

my bad - been a while since I looked into this. Should have known!

[cspotcode]

I finally made the first baby steps implementing this idea. If you're curious, I tried to explain the rationale in the README.md

https://github.com/cspotcode/hookable-typescript/