Compiler API allow custom options in parseCommandLine/ConfigFile

Search Terms

parser options compiler api

Suggestion

Add a way to pass additional custom options to the CLI Parser.

Use Cases

We currently work on a tool transpiling Typescript to Lua.
This works by doing the type checking via the compiler API.
And then transpiling the AST to Lua instead of JS.

We want the user to pass typecheck options via CLI or a tsconfig file. Currently we do that by using parseCommandLine and readConfigFile/parseJsonConfigFileContent which are both exposed by the compiler API. That way the user can use the Lua compiler in the same way he uses tsc.

The issue is that its hard to add custom options into the parse process because parseCommandLine reports an error if an option is invalid. Currently we just ignore errors if they were cause by our custom options but its not a really clean workaround. Same issue for parseJsonConfigFileContent for a workaround there we currently add the options outside compilerOptions{} e.g:

{
  "luaTarget": "5.1",
  "compilerOptions": {...}
}

This also is not real ideal for us.

We don't really want to write our own parser for all tsc options or use some 3rdparty CLI parser in addition to using parseCommandLine.
We also don't really want to use our own typescript fork.

Implementation

It would be ideal if we could just pass our own optionDeclarations based on const optionDeclarations: CommandLineOption[] or OptionNameMap to parseCommandLine and parseJsonConfigFileContent.

One possible way to to this is add a optional parameter to these function that contains an OptionMap and instead of getting the options via getOptionMap / getOptionFromMap that passed parameter would be used.

This would require to merge the additional options with the default options before passing them to the function. An alternative could be that the parameter only gets the additional options and merging is done inside the parser function, that way optionDeclarations would not need to be exposed.

In addition soem option related const/functions/enums might need to be expose.

TL;DR this could be implemented without changing any functionality and only refactoring commandLineParser.ts a bit (EDIT: actually I think it would require a lot of refactoring).
I can also provide you with a PR.

Examples

What we currently do:
https://github.com/Perryvw/TypescriptToLua/blob/master/src/CommandLineParser.ts

We could basically replace most of that with:

let typescriptToLuaOptions: OptionNameMap = {
  // our custom options
}
let commandLine = ts.parseCommandLine(args, typescriptToLuaOptions);

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript / JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. new expression-level syntax)

Start in commandLineParser.ts and trace parseCommandLine, readConfigFile, and parseJsonConfigFileContent, focusing on how option maps are obtained and invalid options are reported. Review the proposed OptionNameMap or option-declaration parameter and determine how custom options should merge with built-in options. Done means both CLI arguments and tsconfig parsing accept custom options without spurious invalid-option errors, while existing behavior remains unchanged.