Skip to content

Javascript tsconfig file (tsconfig.js) #39441

Closed

Description

Search Terms

config
tsconfig.json

Suggestion

It would be very helpful if typescript followed the conventions of pretty much every other JS-stack tool and allowed the configuration to be done as a javascript file so they can more easily be manipulated.
For example all these tools (and many more) already accept configuration files to be javascript:

Prettier -> .prettierrc.js
Jest -> jest.config.js
Webpack -> webpack.config.js
eslint -> .eslintrc.js
styleling -> .stylelintrc.js
lint-staged -> lint-staged.config.js

My suggestion is for typescript tsconfig resolver to look for a tsconfig.js file if available, if so require() it and use the exported values as configuration. If that file is not available then follow the current resolver rules for tsconfig.json.

Use Cases

  • Filesystem introspection
  • Better environment variable toggling of options
  • Easier extensibility of configurations
  • Easier building of tools that include typescript

Examples

module.exports = {
  "includes": [path.resolve(__dirname, process.env.SOURCE_DIR)],
  ...
}
const config = { ... }
if (NODE_ENV === 'development') config.compilerOptions.noUnusedLocals = false
module.exports = config

Right now it is impossible to merge arrays when using the "extends" option of tsconfig.json. If the configuration were javascript files this would be feasible:

const originalConfig = require('some-dep/config/tsconfig.json')
const path = require('path')
module.exports = {
  ...originalConfig,
  includes: [...originalConfig.includes,  path.resolve(__dirname, './mytypes/')]
} 

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. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

Activity

  1. changed the title [-]Javascript config file (tsconfig.js)[/-] [+]Javascript tsconfig file (tsconfig.js)[/+] on Jul 6, 2020
  2. MartinJohns commented on Jul 6, 2020

    @MartinJohns
    Contributor

    Duplicate of #30400. Used search terms: tsconfig.js

  3. StJohn3D commented on Feb 11, 2022

    @StJohn3D

    #30400 should have been marked a duplicate of this one. This issue does a much better job of explaining why we need this feature. one tsconfig.json simply doesn't cut it for more complicated projects.

  4. qodesmith commented on Feb 12, 2022

    @qodesmith

    Why was this issue closed? This is a fantastic suggestion. I'm looking to dynamically set compilerOptions.paths and with json, that's just impossible.

  5. ftzi commented on May 9, 2022

    @ftzi

    Up. Having all the setup json as js files is the future already happening.

  6. faeb187 commented on Mar 24, 2023

    @faeb187

    Aaron Cordova (@qodesmith) actually it's not impossible, it's very easy 👍
    @SrBrahma maybe generating the JSON files is more futuristic 🙏

    1. Just read the file using fs.readFile or fs.readFileSync with option { encoding: "utf8" }
    2. JSON.parse() the string you get
    3. update your JSON however you like dynamically
    4. JSON.stringify() the final JSON before...
    5. write the file back where it belongs using fs.writeFile or fs.writeFileSync

    I was looking if .js is allowed but it's easy to just generate your config files (all of them) then add a CLI or whatever and configure or set some default templates, etc.

  7. Tofandel commented on Jun 20, 2023

    @Tofandel

    Fabio Gartenmann (@faeb187) That would not work if your config includes non encodable content, like functions, which would be the use case for a .js file

  8. qodesmith commented on Jun 24, 2023

    @qodesmith

    Adrien Foulon (@Tofandel) What Fabio Gartenmann (@faeb187) is suggesting is manipulating JSON data by reading, updating, and re-writing the data back to disk. Since the source of truth would be a JSON file, there wouldn't be any non-encodable content. It's essentially the same solution I came up with a while ago, but it's still a hack.

  9. locked as resolved and limited conversation to collaborators on Oct 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    DuplicateAn existing issue was already created

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions