Define a unified "config.json" format

[matthew-dean]

Dear TypeScript community,

Various communities have been trying to solve the same problem: a way to persist the settings passed to a command-line compiler, that is also easily readable by an IDE.

The Less.js discussion: less/less.js#1893
The TypeScript discussion: #1667

I'm sure there are more. TypeScript recently decided to use a tsconfig.json file to serve this need. But, rather than have proprietary / competing config.json formats which litter the root directory of a project, I propose two things, for this community, Less.js's and others:

1. Define a generic config.json format (much like the generic package.json format), that can be expanded with settings for any project (maybe using the package.json name as the key to identify the library?).
2. Define, as a standard, that any config files can be found in the root, OR, secondarily, in a .config folder. Everyone is putting their own "project start" files in root, and our repos are getting cluttered.

For the TypeScript community, it might make sense to support both config.json and tsconfig.json, since the latter is already implemented. The former could simply look like:

{
"typescript": {
    "compilerOptions": {
        "module": "commonjs",
        "noImplicitAny": true,
        "removeComments": true,
        "preserveConstEnums": true,
        "out": "../../built/local/tsc.js",
        "sourceMap": true,
    },
    "files": [
        "core.ts",
        "sys.ts",
        "types.ts",
        "scanner.ts",
        "parser.ts",
        "utilities.ts",
        "binder.ts",
        "checker.ts",
        "emitter.ts",
        "program.ts",
        "commandLineParser.ts",
        "tsc.ts",
        "diagnosticInformationMap.generated.ts"
    ]
  },
"less": { whatever makes sense }
"sass": { ditto }
}

Note: I'm not sure if config.json is too generic a name to use on a widespread basis, but certainly tsconfig.json is too specific to be co-opted by other libraries in an effort for simplicity (and not, by spec, expandable anyway).

What do you think?

[matthew-dean]

As an alternative to this, if people think that the config.json file may get too large if it is expanded with different keys, another option might be to do nothing more than segregate and standardize those config files. As in:

/.config/typescript.json
/.config/less.json
/.config/coffeescript.json

Does that make more sense?

[matthew-dean]

In addition, supplying a schema for the settings of that file is also a brilliant addition, and necessary for IDE integration. I think this is fantastic: http://json.schemastore.org/tsconfig

Would there be a way to standardize that as well (and perhaps define it at the library repo level for discovery)?

[RyanCavanaugh]

I don't know that we're in a position to define a config file standard for the universe of JavaScript tools. If there were a standard already, we would certainly sign on.

Somehow herding together a dozen or so popular tools and getting them all to agree on a file format might be a good way to bootstrap that process, though.

Obligatory https://xkcd.com/927/ 😉

[matthew-dean]

@RyanCavanaugh lol, one of my favorite XKCD comics.

If there were a standard already, we would certainly sign on.

Right, no time like the present? ;-)

Okay, if it's not in TypeScript's wheelhouse right now, that's okay. But as an IDE developer, it's distressing to come across these various config formats. Automatically import the tsconfig.json file? Or just persist those settings to the application configuration storage? What if they change in-app configuration, and also make different changes to tsconfig.json? Sync changes back out? Does that mean writing out and syncing to different config files, in different formats?

Maybe it's not that much of a problem, and people would be happy to define settings twice. Or happy to learn the schema of different config formats. I dunno, it just seems crazy to me right now.

[RyanCavanaugh]

It is crazy. It's just a straightforward example of Tragedy of the Commons -- when you come along and there are 627 different config file formats, adding the 628th doesn't seem like a big deal, and having a config file today is much better for you than waiting (forever) for everyone else to standardize before you make your config file. It's similar to how despite having commandline tools for over 40 years, there's still no universal commandline format!

It's going to be very difficult to solve that problem because anyone who tries to move to a putative standard is going to expend resources to deal with two formats at once, but with no guarantee that everyone else is going to move to the same standard.

A recognized standards body providing an official recommendation, or a quorum of major players all simultaneously announcing their intent to move to the same standard, would really be the only plausible first steps.