Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

typedoc does not respect tsconfig.json include and entryPoint should be supplied manually. #1515

Closed
hdi-amiri opened this issue Feb 21, 2021 · 4 comments
Labels
bug Functionality does not match expectation

Comments

@hdi-amiri
Copy link

Search terms

typedoc, tsconfig, include, exclude

Expected Behavior

I have the following tsconfig.json file:

{
  "compilerOptions": {
    "allowSyntheticDefaultImports": true,
    "allowUnreachableCode": false,
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "lib": ["dom", "es2017"],
    "moduleResolution": "node",
    "module": "commonjs",
    "target": "es2017",
    "inlineSources": true,
    "noImplicitAny": true,
    "outDir": "dist",
    "sourceMap": true,
    "strictNullChecks": true,
    "declarationDir": "dist/types",
    "skipLibCheck": true
  },
  "include": ["src"],
  "exclude": ["node_modules"],
  "typedocOptions": {
    "excludePrivate": true,
    "excludeProtected": true,
    "excludeInternal": true,
    "exclude": [
      "types/jsx.d.ts",
      "**/*+(e2e|spec|index).ts",
      "**/*spec.tsx",
      "**/*.model.ts",
      "**/environment/*.ts",
      "**/components.d.ts",
      "**/components/common/*",
      "**/*+(e2e|spec|index).ts",
      "**/*spec.tsx",
      "**/*.model.ts",
      "**/environment/*.ts",
      "**/core.d.ts"
    ],
    "json": "json-doc",
    "out": "core-doc",
    "name": "core",
    "includeVersion": true,
    "readme": "readme.md",
    "showConfig": false
  }
}

I expect that when I enter the following command in terminal, the output be generated, but It doesn't work.

$ typedoc

But when I change it to this, it works as expcted:

$typedoc src

Actual Behavior

The following output is shown:

$ typedoc
Error: No entry points provided

Steps to reproduce the bug

Environment

  • Typedoc version: 0.20.26
  • TypeScript version: 4.1.5
  • Node.js version: 12.18.2
  • OS: Windows
@hdi-amiri hdi-amiri added the bug Functionality does not match expectation label Feb 21, 2021
@Gerrit0
Copy link
Collaborator

Gerrit0 commented Feb 21, 2021

entryPoint should be supplied manually.

Yes! It should.

For the vast majority of cases, the include you give to TypeScript, and the entryPoints you give to TypeDoc should be different. They describe two different features.

include means "all of the files necessary to compile this project"
entryPoints means "what files users of this library may import"

For many projects, entryPoints should be a single file - src/index.ts or similar. TypeDoc will then examine what is exported from that file and document it - leaving your internal functions/modules that consumers of the library should not use undocumented. TypeDoc's own documentation does this:

https://github.com/TypeStrong/typedoc-site/blob/5cf54eb16c05dabf5cd3fd27b36ddbc1ab469401/typedoc.json#L1-L8

{
    "out": "../_site/api",
    "json": "../_site/api/docs.json",
    "name": "TypeDoc Documentation",
    "excludeExternals": true,
    "includeVersion": true,
    "entryPoints": ["src/index.ts"]
}

There has been some discussion in #1485 about automatically detecting the entry point using the main field from package.json, which I'm still considering...

@hdi-amiri
Copy link
Author

Thanks for your quick response!
What you say I guess is in contradiction with what is stated here, Or maybe I misinterpreted it!

When TypeDoc loads a tsconfig.json file, it will read options declared under the typedocOptions key and take the tsconfig.json's input files (as defined by files or include/exclude) as the input files.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Feb 21, 2021

Oh! That makes sense why you thought what you did then. I must have forgotten to update that part of the page when 0.20 was released. That was accurate for older versions of TypeDoc... I'll update that shortly.

@hdi-amiri
Copy link
Author

Thanks!

Gerrit0 added a commit to TypeStrong/typedoc-site that referenced this issue Feb 21, 2021
squaremo added a commit to pulumi/pulumi that referenced this issue Jun 27, 2022
.. and consequently, the type therein `InvokeOptions`, in generated
docs. All functions in Pulumi SDKs take an InvokeOptions-typed argument,
and all the generated documentation for those functions has a broken
link because it's not part of the NodeJS SDK documentation generated for
pulumi/pulumi.

The version of TypeDoc used is quite old, and I suspect it consults
`tsconfig.json` to find the source files (evidence: someone complaining
that it does not do this well enough:
TypeStrong/typedoc#1515). I have
conservatively just added the file in question to `files`, since:

 - I'm not sure if .files should list _all_ the files
 - Upgrading TypeDoc would surely have many unintended consequences

Signed-off-by: Michael Bridgen <mbridgen@pulumi.com>
squaremo added a commit to pulumi/pulumi that referenced this issue Jun 28, 2022
…tation (#9973)

* Make tsconfig.json valid JSON

* Include invoke.ts in tsconfig.files

.. and consequently, the type therein `InvokeOptions`, in generated
docs. All functions in Pulumi SDKs take an InvokeOptions-typed argument,
and all the generated documentation for those functions has a broken
link because it's not part of the NodeJS SDK documentation generated for
pulumi/pulumi.

The version of TypeDoc used is quite old, and I suspect it consults
`tsconfig.json` to find the source files (evidence: someone complaining
that it does not do this well enough:
TypeStrong/typedoc#1515). I have
conservatively just added the file in question to `files`, since:

 - I'm not sure if .files should list _all_ the files
 - Upgrading TypeDoc would surely have many unintended consequences
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Functionality does not match expectation
Projects
None yet
Development

No branches or pull requests

2 participants