I have created an installable package. Please try it. Thanks.

https://github.com/tani/deno-init

I don't think we want to enoucrage many projects to be created with all the possible compiler options because generally people should not be changing any of the compiler options.

If we do have this command, perhaps just have all the settings mostly empty, which should be a sufficient starting point. The LSP provides autocomplete to explore other options.

I am also not in favour. The CLI is designed to have sensible defaults and to allow incremental changes when those defaults don't make sense for a particular context. That would reduce an init command to writing out an empty deno.jsonc, which doesn't make a huge amount of sense. We should always aim to keep config minimal and by "exception" and an init feels like it would undermine that principal.

If we do have this command, perhaps just have all the settings mostly empty

Rather than empty, this could be solved by generating the file as .jsonc with all defaults present as literals, and all lines in the object commented out. Doing so would preserve all defaults (even if they change in subsequent releases) while still providing a template for accessible discovery without tooling and quick enablement/customization of individual options.

{
  // "compilerOptions": {
  //   "allowJs": true,
  //   "allowUnreachableCode": false,
  //   "allowUnusedLabels": false,
  //   "checkJs": false,
  //   "experimentalDecorators": true,
  //   "jsx": "react",
  //   "jsxFactory": "React.createElement",
  //   "jsxFragmentFactory": "React.Fragment",
  //   "jsxImportSource": "react",
  //   "keyofStringsOnly": false,
  //   "lib": [
  //     "deno.window"
  //   ],
  //   "noFallthroughCasesInSwitch": false,
  //   "noImplicitAny": true,
  //   "noImplicitReturns": false,
  //   "noImplicitThis": true,
  //   "noImplicitUseStrict": true,
  //   "noStrictGenericChecks": false,
  //   "noUnusedLocals": false,
  //   "noUnusedParameters": false,
  //   "noUncheckedIndexedAccess": false,
  //   "strict": true,
  //   "strictBindCallApply": true,
  //   "strictFunctionTypes": true,
  //   "strictPropertyInitialization": true,
  //   "strictNullChecks": true,
  //   "suppressExcessPropertyErrors": false,
  //   "suppressImplicitAnyIndexErrors": false
  // },
  // "lint": {
  //   "files": {
  //     "include": [],
  //     "exclude": []
  //   },
  //   "rules": {
  //     "tags": [],
  //     "exclude": [],
  //     "include": []
  //   }
  // },
  // "fmt": {
  //   "files": {
  //     "include": [],
  //     "exclude": []
  //   },
  //   "options": {
  //     "useTabs": false,
  //     "lineWidth": 80,
  //     "indentWidth": 2,
  //     "singleQuote": false,
  //     "proseWrap": "always"
  //   }
  // }
}

@jsejcksn Thank you for the suggestion! How about this script?

function generate(schema: any): any {
  if ("default" in schema) {
    return schema.default;
  }
  if ("type" in schema) {
    switch (schema.type) {
      case "object":
        return Object.fromEntries(
          Object.entries(schema.properties).map(([key, value]) => {
            return [key, generate(value)];
          }),
        );
      case "array":
        return [];
    }
  }
}

const schemaUrl =
  "https://deno.land/x/[email protected]/cli/schemas/config-file.v1.json";
const response = await fetch(schemaUrl);
const schema = await response.json();
const config = JSON.stringify(generate(schema), null, 2);
for(const line of config.split('\n')) {
  if (!line.includes('{}') && !line.includes('[]') && (line.match(/[{}\[\]]/))) {
    console.log(line)
  } else {
    console.log('//'+line)
  }
}

This script produces the JSONC as follows.

{
  "compilerOptions": {
//    "allowJs": true,
//    "allowUnreachableCode": false,
//    "allowUnusedLabels": false,
//    "checkJs": false,
//    "experimentalDecorators": true,
//    "jsx": "react",
//    "jsxFactory": "React.createElement",
//    "jsxFragmentFactory": "React.Fragment",
//    "jsxImportSource": "react",
//    "keyofStringsOnly": false,
    "lib": [
//      "deno.window"
    ],
//    "noFallthroughCasesInSwitch": false,
//    "noImplicitAny": true,
//    "noImplicitReturns": false,
//    "noImplicitThis": true,
//    "noImplicitUseStrict": true,
//    "noStrictGenericChecks": false,
//    "noUnusedLocals": false,
//    "noUnusedParameters": false,
//    "noUncheckedIndexedAccess": false,
//    "strict": true,
//    "strictBindCallApply": true,
//    "strictFunctionTypes": true,
//    "strictPropertyInitialization": true,
//    "strictNullChecks": true,
//    "suppressExcessPropertyErrors": false,
//    "suppressImplicitAnyIndexErrors": false
  },
  "lint": {
    "files": {
//      "include": [],
//      "exclude": []
    },
    "rules": {
//      "tags": [],
//      "exclude": [],
//      "include": []
    }
  },
  "fmt": {
    "files": {
//      "include": [],
//      "exclude": []
    },
    "options": {
//      "useTabs": false,
//      "lineWidth": 80,
//      "indentWidth": 2,
//      "singleQuote": false,
//      "proseWrap": "always"
    }
  }
}

How about this script?

@tani It's probably better to think about the actual implementation after there is consensus about the content and format. Here are some thoughts in regard to that:

• All lines should be commented out within the JSON object (including the top-level properties)

• Including descriptions would also be useful:

  Either:

  • An inline comment using the plaintext description:

    {
      // "compilerOptions": {
      //   "allowJs": true, // Allow JavaScript files to be a part of your program. Use the `checkJS` option to get errors from these files.
      // }
    }

  • A JSDoc comment using the markdown description

    {
      // "compilerOptions": {
      //   /**
      //    * Allow JavaScript files to be a part of your program. Use the `checkJS` option to get errors from these files.
      //    * 
      //    * See more: https://www.typescriptlang.org/tsconfig#allowJs
      //    */
      //   "allowJs": true,
      // }
    }

And getting the schema for the current version of Deno is obviously important:

`https://deno.land/x/deno@v${Deno.version.deno}/cli/schemas/config-file.v1.json`

"deno init" subcommand was added in #15469

@bartlomieju The possibility of generating a config file (as described in this issue) is mentioned in the PR, but it doesn't look like the PR actually included this feature. Since you closed this issue, is that a signal of "no interest to implement"?

@bartlomieju The possibility of generating a config file (as described in this issue) is mentioned in the PR, but it doesn't look like the PR actually included this feature. Since you closed this issue, is that a signal of "no interest to implement"?

I've reopened the issue. For now we're shipping a first iteration of deno init that doesn't add any configurability. If you have use case for that please leave a comment or upvote.

I've reopened the issue.

@bartlomieju Thanks! Maybe we can change the title to reflect the more specific nature of this suggestion in comparison to what was merged.

I'm not sure the deno init command as of Deno 1.25 does enough to warrant its name/existence? For example, npm init scaffolds a package name/version/entrypoint/etc. to generate something configurable that would actually be used/kept in a project built from that scaffold. deno init just generates a couple of example files with code that most likely wouldn't be kept for most projects, and that wouldn't be useful to developers with any past experience with Deno - it seems like a command that a users migrating from Node might try once and then never need again, more of a deno gen-example than a deno init.

A more useful deno init probably needs to scaffold out some basic configuration items - not necessarily for the compiler, it makes sense to favour the defaults for that, but for e.g. generating an import map and adding a project entrypoint as a deno task.

to expand upon @dragonwocky, I think that npm does something pretty useful, with the npm create svelte@latest, which as I understand it, simply runs a script in a package with create-<param>. I believe we can get a similar workflow in deno with deno init --script https://deno.land/x/oak/init.ts or something similar. I suppose this could be considered a different command too (like deno create https://deno.land/x/oak/init.ts), but either way this would be a nice normalizing of workflows for all the frameworks in deno (like oak, or even fresh, which just runs a generic command deno run -A -r https://fresh.deno.dev my-project)

I don't think this has anything actionable for us to do regarding deno init. If there are concrete suggestions for features we should add to deno init, please open separate issues.