I suggest allowing a tsconfig.js or tsconfig.ts as an optional alternative to tsconfig.json.
What do you want to use this for? Primarily to add comments to the tsconfig file.
What shortcomings exist with current approaches? JSON does not allow comments. You can't even hack in comments by adding fake fields like "_explanationOfTypeRoots", as the build complains about unknown compiler options and stops.
Many tools and frameworks allow javascript config files. Jest, for example. jest --init produces a heavily commented config file, which is very useful for beginners.
What do you want to use this for? Primarily to add comments to the tsconfig file.
Did you know that you can add comments to tsconfig.json?
Try it with tsc --init, that produces a heavily commented tsconfig.json file. Here a example generated with typescript 3.3.3333:
{
"compilerOptions": {
/* Basic Options */
"target": "es5", /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017','ES2018' or 'ESNEXT'. */
"module": "commonjs", /* Specify module code generation: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', or 'ESNext'. */
// "lib": [], /* Specify library files to be included in the compilation. */
// "allowJs": true, /* Allow javascript files to be compiled. */
// "checkJs": true, /* Report errors in .js files. */
// "jsx": "preserve", /* Specify JSX code generation: 'preserve', 'react-native', or 'react'. */
// "declaration": true, /* Generates corresponding '.d.ts' file. */
// "declarationMap": true, /* Generates a sourcemap for each corresponding '.d.ts' file. */
// "sourceMap": true, /* Generates corresponding '.map' file. */
// "outFile": "./", /* Concatenate and emit output to single file. */
// "outDir": "./", /* Redirect output structure to the directory. */
// "rootDir": "./", /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */
// "composite": true, /* Enable project compilation */
// "removeComments": true, /* Do not emit comments to output. */
// "noEmit": true, /* Do not emit outputs. */
// "importHelpers": true, /* Import emit helpers from 'tslib'. */
// "downlevelIteration": true, /* Provide full support for iterables in 'for-of', spread, and destructuring when targeting 'ES5' or 'ES3'. */
// "isolatedModules": true, /* Transpile each file as a separate module (similar to 'ts.transpileModule'). */
/* Strict Type-Checking Options */
"strict": true, /* Enable all strict type-checking options. */
// "noImplicitAny": true, /* Raise error on expressions and declarations with an implied 'any' type. */
// "strictNullChecks": true, /* Enable strict null checks. */
// "strictFunctionTypes": true, /* Enable strict checking of function types. */
// "strictBindCallApply": true, /* Enable strict 'bind', 'call', and 'apply' methods on functions. */
// "strictPropertyInitialization": true, /* Enable strict checking of property initialization in classes. */
// "noImplicitThis": true, /* Raise error on 'this' expressions with an implied 'any' type. */
// "alwaysStrict": true, /* Parse in strict mode and emit "use strict" for each source file. */
/* Additional Checks */
// "noUnusedLocals": true, /* Report errors on unused locals. */
// "noUnusedParameters": true, /* Report errors on unused parameters. */
// "noImplicitReturns": true, /* Report error when not all code paths in function return a value. */
// "noFallthroughCasesInSwitch": true, /* Report errors for fallthrough cases in switch statement. */
/* Module Resolution Options */
// "moduleResolution": "node", /* Specify module resolution strategy: 'node' (Node.js) or 'classic' (TypeScript pre-1.6). */
// "baseUrl": "./", /* Base directory to resolve non-absolute module names. */
// "paths": {}, /* A series of entries which re-map imports to lookup locations relative to the 'baseUrl'. */
// "rootDirs": [], /* List of root folders whose combined content represents the structure of the project at runtime. */
// "typeRoots": [], /* List of folders to include type definitions from. */
// "types": [], /* Type declaration files to be included in compilation. */
// "allowSyntheticDefaultImports": true, /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */
"esModuleInterop": true /* Enables emit interoperability between CommonJS and ES Modules via creation of namespace objects for all imports. Implies 'allowSyntheticDefaultImports'. */
// "preserveSymlinks": true, /* Do not resolve the real path of symlinks. */
/* Source Map Options */
// "sourceRoot": "", /* Specify the location where debugger should locate TypeScript files instead of source locations. */
// "mapRoot": "", /* Specify the location where debugger should locate map files instead of generated locations. */
// "inlineSourceMap": true, /* Emit a single file with source maps instead of having a separate file. */
// "inlineSources": true, /* Emit the source alongside the sourcemaps within a single file; requires '--inlineSourceMap' or '--sourceMap' to be set. */
/* Experimental Options */
// "experimentalDecorators": true, /* Enables experimental support for ES7 decorators. */
// "emitDecoratorMetadata": true, /* Enables experimental support for emitting type metadata for decorators. */
}
}
Oh, nice! I was under the impression that comments were not allowed in JSON, but it makes sense that someone would write a parser that allows them. Thank you for your response, I am closing the issue because I no longer think this feature is necessary.
@alexmiddeleer No, YOU are right -- JavaScript style comments aren't allowed in JSON; tsc --init produces an invalid JSON file. The parser, of course, is permissive.
@msftgits should consider an alternative format for autogenerated config files. This could be solved easily by allowing tsconfig.yaml, tsconfig.js, or tsconfig.ts while continuing to support tsconfig.json in perpetuity.
EDIT: I'm guessing the parser just interprets the content of tsconfig.json as JavaScript
I agree that more config options would be ideal. But I鈥檓 guessing the core team needs to focus on higher priority items. Maybe this would be a good first contribution for someone new.
This format is known as JSON5
EDIT: I'm guessing the parser just interprets the content of tsconfig.json as JavaScript
JSON is a different top-level production because the initial { indicates an object, not a statement block.
We are not accepting PRs to turn config into an executable thing. This opens up an enormous can of worms (is it safe to run this? what dependencies does the config file have? what does the config file assume about its environment?) that we'd prefer remain closed.
@RyanCavanaugh you said
We are not accepting PRs to turn config into an executable thing.
Would you accept a PR to support _only_ yaml? Or for that matter, other non-executable formats (e.g. toml, ini, etc, but I'm only interested in yaml).
Most helpful comment
I agree that more config options would be ideal. But I鈥檓 guessing the core team needs to focus on higher priority items. Maybe this would be a good first contribution for someone new.