AssertionError: "Tried to access Context.program when not converting a source file."

Question

AssertionError: "Tried to access Context.program when not converting a source file."

BobKerns opened this issue 4 years ago · comments

In 4.0.0 and beyond, I get this error, on my template project that only has a single.ts trivial file and a couple README.md files.

Info: Loaded plugin /Users/rwk/p/npm-typescript-rollup-template/node_modules/typedoc-plugin-external-module-name
Info: Loaded plugin /Users/rwk/p/npm-typescript-rollup-template/node_modules/typedoc-plugin-mermaid
Info: Loaded plugin /Users/rwk/p/npm-typescript-rollup-template/node_modules/typedoc-plugin-npm-externals
TypeDoc exiting with unexpected error:
AssertionError [ERR_ASSERTION]: Tried to access Context.program when not converting a source file
at Context.get program [as program] (/Users/rwk/p/npm-typescript-rollup-template/node_modules/typedoc/dist/lib/converter/context.js:39:18)
at ExternalModuleNamePlugin.onBegin (/Users/rwk/p/npm-typescript-rollup-template/node_modules/typedoc-plugin-external-module-name/typedoc-plugin-external-module-name.js:85:37)
at triggerEvents (/Users/rwk/p/npm-typescript-rollup-template/node_modules/typedoc/dist/lib/utils/events.js:173:43)
at triggerApi (/Users/rwk/p/npm-typescript-rollup-template/node_modules/typedoc/dist/lib/utils/events.js:149:13)
at eventsApi (/Users/rwk/p/npm-typescript-rollup-template/node_modules/typedoc/dist/lib/utils/events.js:42:18)
at Converter.trigger (/Users/rwk/p/npm-typescript-rollup-template/node_modules/typedoc/dist/lib/utils/events.js:371:13)
at Converter.convert (/Users/rwk/p/npm-typescript-rollup-template/node_modules/typedoc/dist/lib/converter/converter.js:41:14)
at Application.convert (/Users/rwk/p/npm-typescript-rollup-template/node_modules/typedoc/dist/lib/application.js:151:31)
at run (/Users/rwk/p/npm-typescript-rollup-template/node_modules/typedoc/bin/typedoc:59:25)
at Object. (/Users/rwk/p/npm-typescript-rollup-template/node_modules/typedoc/bin/typedoc:26:1) {
generatedMessage: false,
code: 'ERR_ASSERTION',
actual: undefined,
expected: true,
operator: '=='
}

It works in 3.1.0

Typedoc: 0.20.4
Typescript: 4.1.3

Bob Kerns · Answer 1 · Wed Dec 30 2020 18:57:12 GMT+0800 (China Standard Time)

I suspect this problem may have arisen with typedoc 0.20.0, which I believe changed around the converters. Earlier versions of typedoc aren't compatible with typescript 4.1.x, so I didn't explore back further to confirm.

Gerrit Birkeland · Answer 2 · Thu Dec 31 2020 15:05:22 GMT+0800 (China Standard Time)

FWIW - this plugin is likely partially obsolete with 0.20. This plugin lets you emulate library mode by manually grouping reflections into modules via @module. In 0.20, typedoc proper figures this out by looking at your exports (and happens to let you rename the module with @module)

The one rather big place where this plugin is still necessary is when dealing with merging modules - I'm not sure many packages will need to do this, but typedoc doesn't do it.

Kevin Sidwar · Answer 3 · Sun Jan 03 2021 01:38:19 GMT+0800 (China Standard Time)

In 0.20, typedoc proper figures this out by looking at your exports (and happens to let you rename the module with @module)

@Gerrit0 Is this documented somewhere? I'm trying to figure out how to fix my "Class default" everywhere and haven't been able to. Any help would be appreciated.

Gerrit Birkeland · Answer 4 · Sun Jan 03 2021 02:00:05 GMT+0800 (China Standard Time)

Is this documented somewhere?

It is mentioned in the 0.20 release notes - https://github.com/TypeStrong/typedoc/releases/tag/v0.20.0
I've added a note to the doc comments page on the site - https://typedoc.org/guides/doccomments/#files

I'm trying to figure out how to fix my "Class default" everywhere and haven't been able to.

In 0.20, TypeDoc documents your library as it appears to the user. If you default export something, then it is exported as default, so that's the name TypeDoc will use. Using any other name is lying to whoever is reading the docs.

The obvious fix to this is to stop using default exports.... which I support wholeheartedly. You could also offer both default exports and named exports, at which point TypeDoc will use the definition order to determine the name:

class X {}
export { X }
export default X

Will result in X showing up as itself in the documentation, with a default member as a re-export pointing to X.

However, if you are seeing this in a bunch of places, this probably means you are giving TypeDoc more than one entry point. Chances are, you should only be giving TypeDoc your top level entry point, src/index.ts(x). 0.20 will use TypeScript to get all of the exports from that file and use those exported names when generating documentation.

Chris Thielen · Answer 5 · Tue Jan 05 2021 05:24:25 GMT+0800 (China Standard Time)

I pushed a branch https://github.com/christopherthielen/typedoc-plugin-external-module-name/tree/typedoc-0.20-compat that handles multiple programs, but I haven't determined if it is otherwise compatible with typedoc 0.20.x

François Romain · Answer 6 · Thu Jan 28 2021 01:03:31 GMT+0800 (China Standard Time)

@christopherthielen @Gerrit0 this plugin is still very relevant.

I would prefer not to manually add @module comments in every files, when a plugin can do the job.
thank you

Geoff Baum · Answer 7 · Fri Feb 19 2021 02:28:51 GMT+0800 (China Standard Time)

FWIW, I downgraded to typedoc 0.19.2 and the issues are gone. I'll just do that for now since I'm not using anything in ^0.20.1 at the moment.

Plopsi · Answer 8 · Tue Mar 16 2021 15:50:32 GMT+0800 (China Standard Time)

Hello, I ran into the same problem after typedoc update. And it seems the compat branch is broken. We used the plugin because of it merging behaviour of same @module in different files and the separation of dots in the module name for navigation.

For now we also stay on 0.19 with 0.4.5.