[feature request] Support extending Deno configs

[niedzielski]

This is a feature request to add an extends-like option to deno.json like tsconfig.json has. Eg, consider a shared common config, deno-base.json:

// deno-base.json
{
  "compilerOptions": {
    "noImplicitOverride": true,
    "noUncheckedIndexedAccess": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "useUnknownInCatchVariables": true
  }
}

The common config could be mixed into a specific usage to avoid repeating all the common settings:

//  subproject/deno.json
{
  "extends": "../deno-base.jsonc",
  "compilerOptions": {
    // All the options set in deno-base.json apply here.
    "exactOptionalPropertyTypes": true
  }
}

Example use case

I have multi-Deno config project where each project has its own deno.json:

polyrepo
  deno.json
  sub-a
    deno.json
  sub-b
    deno.json

Each config has a lot of overlap and I think I could share some of it if a TypeScript-like extends option was supported.

// Example polyrepo root config.
{
  // https://deno.land/manual@main/typescript/configuration
  "compilerOptions": {
    "exactOptionalPropertyTypes": true,
    "noImplicitOverride": true,
    "noUncheckedIndexedAccess": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "useUnknownInCatchVariables": true,
    "lib": ["dom", "deno.ns"]
  },
  "fmt": {
    "files": {
      "exclude": ["dist", "mem/dist", "linear-text", "nature-elsewhere"]
    },
    "options": { "semiColons": false, "singleQuote": true }
  },
  "imports": {
    "@/atlas-pack": "./atlas-pack/mod.ts",
    "@/green-field": "./demos/green-field/mod.ts",
    "@/mem": "./mem/mod.ts",
    "@/nttt": "./nttt/mod.ts",
    "@/ooz": "./ooz/mod.ts",
    "@/solitaire": "./solitaire/mod.ts",
    "@/super-patience": "./super-patience/mod.ts",
    "@/void": "./void/mod.ts",
    "std/": "https://deno.land/[email protected]/"
  },
  "lint": {
    "files": {
      "exclude": ["dist", "mem/dist", "linear-text", "nature-elsewhere"]
    },
    "rules": {
      "exclude": ["no-empty-interface", "no-inferrable-types", "no-namespace"]
    }
  },
  "lock": false,
  "test": {
    "files": {
      "exclude": ["dist", "mem/dist", "linear-text", "nature-elsewhere"]
    }
  }
}

// Example submodule config.
{
  // https://deno.land/manual@main/typescript/configuration
  "compilerOptions": {
    "exactOptionalPropertyTypes": true,
    "noImplicitOverride": true,
    "noUncheckedIndexedAccess": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "useUnknownInCatchVariables": true,
    "lib": ["dom", "deno.ns"]
  },
  "fmt": {
    "files": { "exclude": ["dist"] },
    "options": { "semiColons": false, "singleQuote": true }
  },
  "imports": {
    "@/atlas-pack": "./mod.ts",
    "@/ooz": "https://deno.land/x/[email protected]/mod.ts",
    "std/": "https://deno.land/[email protected]/"
  },
  "lint": {
    "files": { "exclude": ["dist"] },
    "rules": {
      "exclude": ["no-empty-interface", "no-inferrable-types", "no-namespace"]
    }
  },
  "lock": false,
  "test": { "files": { "exclude": ["dist"] } }
}

I feel it's hard to share the config well but maybe a good start would be deep merging compilerOptions, fmt.options, lint.rules, and lock.

References

Some loosely related references:

• https://www.typescriptlang.org/tsconfig#extends
• Proposal: add permissions to config file #12763
• [feature request] Add top-level files deno.json config to replace fmt.files + lint.files + test.files #15300
• Idea: Deno Workspace #4275
• Support deno.config in a multi-root workspace vscode_deno#501
• https://github.com/denoland/vscode_deno/blob/main/docs/workspaceFolders.md#mixed-deno-projects

[lino-levan]

Melodramatically, are we really at the point where deno configuration is so necessary and burdensome that extends as a proposal makes sense? In my ideal world, there would be maybe one deno.jsonc for the whole monorepo but maybe I'm just being idealistic.

[niedzielski]

I hope most projects never need it.

This feature is useful for polyrepos and large projects that have multiple subprojects each with their own deno.json files. I think this will be common enough (but I'm interested to see polyrepo counterexamples that wouldn't use it). The shared configuration itself is wanted for Deno as much as TypeScript itself (compilerOptions) which offers numerous options as noted in the issue.

[igl]

I think this will be common enough

There are 2 aspects to this:

1. Having a project understand it's sharing code/import_maps from other deno.json files (via nesting with features like "workspaces" and "extends")
2. Having the language server understand that there are 2 separate folders with Individual deno.json files.
   Currently it only supports 1 deno.json file from the root, or another location via deno.enablePaths.

The second one is the biggest problem as it prevents mono-repos for deno to exist at all. Only 1 deno.json is in control of the LSP

[hildjj]

This would be particularly useful for the fmt and lint properties. I would like all of my projects to have the same formatting.

[BOLL7708]

The second one is the biggest problem as it prevents mono-repos for deno to exist at all. Only 1 deno.json is in control of the LSP

Ah, so only the root deno.json decides all the compile options even if I have more deno.json files in the project?

I am working on a project where a deno.json in one folder runs code generation, and another deno.json in another folder runs the actual application using said generated code. I could combine them if that is what is currently supported, it should be fairly straight forward.

I was also looking into doing a shared compile options .json, which is why I ended up here, but if I'm already combining the configs that is no longer something I need. I'll just add navigation into the folders in the tasks and put all the tasks in the same file, done!

[igl]

The second one is the biggest problem as it prevents mono-repos for deno to exist at all. Only 1 deno.json is in control of the LSP

Ah, so only the root deno.json decides all the compile options even if I have more deno.json files in the project?

I am working on a project where a deno.json in one folder runs code generation, and another deno.json in another folder runs the actual application using said generated code. I could combine them if that is what is currently supported, it should be fairly straight forward.

I was also looking into doing a shared compile options .json, which is why I ended up here, but if I'm already combining the configs that is no longer something I need. I'll just add navigation into the folders in the tasks and put all the tasks in the same file, done!

Deno now supports workspaces.

The imports map is already inherited from the root deno.json but other compiler/fmt/lint options are not afaik.

[BOLL7708]

I've now spent two evenings trying to get workspaces to work with Fresh, so I can have Fresh in a separate folder to the rest of my old codebase, and hopefully have separate imports for them. But, I just get errors from Fresh, it feels like it cannot exist as a workspace 😅 Oh the frustration! Guess I could post an issue on the Fresh repo.

[Swimburger]

I'm investigating if it's feasible to move a pnpm node monorepo to Deno, and every project (many of them) has their own tsconfig.json that extends from a shared one.
Not having to duplicate this configuration in deno.json all over the place would be very helpful.

Mostly the configuration is the same, but sometimes it inherits from a separate shared tsconfig file for testing projects.

Since it's a large monorepo, we need to be able to adopt Deno incrementally.