Getting random project id

[liorcohen55551]

Search terms

random project id value

Expected Behavior

Generated TypeDoc for the same npm package input will be the same for all CI runs

Actual Behavior

Generated TypeDoc project gets random ids causing the whole objects to get different ids on every CI run.

Steps to reproduce the bug

We have a service that generates npm packages, then creates Typedoc for the generated package and commit all the code to github, we noticed that we have a lot of dummy commits where ids changed only, without any change in the npm pakcage source code, for example:

{
  "typeDocModel": {
    "id": 9053,
    "name": "some_project1",
    "variant": "project",
    "kind": 1,
    "flags": {},
    "children": [
      {
        "id": 9072,
  

changed to:

{
  "typeDocModel": {
    "id": 99,
    "name": "some_project1",
    "variant": "project",
    "kind": 1,
    "flags": {},
    "children": [
      {
        "id": 118,

and then changed to

{
  "typeDocModel": {
    "id": 0,
    "name": "some_project1",
    "variant": "project",
    "kind": 1,
    "flags": {},
    "children": [
      {
        "id": 19,

And thats the only changes in the commit.. (no npm page source file changed).

How is it possible? Do we have a way to set the project initial id so all the other ids will be the same per run? Do we have a different way to do it?

Environment

• Typedoc version: 0.24.8
• TypeScript version: 4.7.4
• Node.js version: 18.18.2
• OS:

How do we run it:

import { Application, TSConfigReader } from 'typedoc';

  const app = new Application();

  // If you want TypeDoc to load tsconfig.json / typedoc.json files
  app.options.addReader(new TSConfigReader());

  app.bootstrap({
    basePath,
    readme: 'none',
    disableSources,
    entryPoints: entryPoints.map((ep) => path.join(basePath, ep)),
    tsconfig: tsconfigPath,
    commentStyle: 'all', // Use both block and line comments
    excludeExternals,
    skipErrorChecking: true,
    name,
  });

[Gerrit0]

Generated IDs are not randomized. They are sequentially assigned for each created reflection. It sounds to me like you're generating multiple projects in different orders as the root level project will always have ID 0 if only generating one project.

TypeDoc provides the resetReflectionID function to reset it, but if you combine reflections objects from multiple invocations of TypeDoc after calling that, the behavior is completely undefined.

[liorcohen55551]

As you can see in the attached image, I have only one project ("kind": 1):

[Gerrit0]

It is impossible to say what is going on with your setup without a reproduction.

You are only saving one project, but it clearly isn't the first one created, which tells me that more than one is being converted.

[liorcohen55551]

We have a service that generates npm packages. Are you suggesting that the reason the project ID doesn't reset to 0 is because this service is continuously creating more packages? if so I can just call resetReflectionID before creating the typedoc

[Gerrit0]

Yes, that's exactly what I'm saying. That ID is a global which is incremented while typedoc is running. M

[liorcohen55551]

Got it now, thanks for the detailed explanation!

Maybe it's possible to add an option resetReflectionID that will reset this variable in the object constructor instead of having a separate function for reseting it?

Something like:

 app.bootstrap({
    basePath,
    readme: 'none',
    resetReflectionID: true, // => Reseting the reflection ID
    disableSources,
    entryPoints: entryPoints.map((ep) => path.join(basePath, ep)),
    tsconfig: tsconfigPath,
    commentStyle: 'all', // Use both block and line comments
    excludeExternals,
    skipErrorChecking: true,
    name,
  });

[Gerrit0]

That option isn't suitable for general use, and wouldn't make sense to set in any usage which isn't programmatic where multiple conversions are being done.

Further, putting the option there would imply that's when resetting should be done, which isn't true. Both TypeDoc's usage and several plugin's test code's usage of that is to reset several many for a single application instance during unit testing. If anywhere it would make sense as an option to one of the convert functions, but as it modifies global state I prefer the API which makes it obvious that something fishy is going on.

[liorcohen55551]

Could you please clarify why we might choose not to reset the index? Wouldn't it be preferable to assign a the same initial ID (0) to each execution? It seems a bit unusual for the class to maintain state that changes between runs.