Local file path stored in docs

[btgoodwin]

I'm using the following configuration for my project:

{
    "theme": "minimal",
    "module": "commonjs",
    "target": "ES6",
    "readme": "README.md",
    "mode": "file",
    "exclude": "./**/*+(e2e|spec|index).ts",
    "excludePrivate": "true"
}

And I'm running TypeDoc (v0.9.0): typedoc --options typedoc.json --out docs src/lib.

My output documentation results in references to modules in node_modules with the path stored in the documentation itself. In other words, I'll end up with lines like this:

Inherited from <some external name>
Defined in /home/my_user/.../node_modules/<external library>/...

I've tried using the externalPattern set to ./node_modules/**/* and excludeExternal, but it ends up excluding my entire module (i.e., the documentation is just an index file with my readme in it).

What is the correct configuration to prevent references to my local filesystem ending up in my published documentation?

[btgoodwin]

Never mind, I found someone else's response in a different issue thread that indicated using "exclude": "**/node_modules/**" was the way to go. That seems to have resolved it for me (i.e., preventing it from providing my local host's file system paths into the documentation).

[btgoodwin]

Actually, that didn't fix it. On the local copy of the generated docs, whole offending sections of the documentation are no longer visible. Once it was published, all of those sections are now visible and of course have /home/user... embedded into them despite having set "exclude": "**/node_modules/**".

It's still unclear how to prevent it from pulling in those external links.

[sdirix]

We have the same problem. Would be great if this could be fixed at some point. An easy workaround would be to not provide a Defined in path when it can't be resolved properly. The Inherited information is sufficient.

[iliveoncaffiene]

Working on a team project with this issue is a huge annoyance. All node_modules paths are local paths and update every time someone else works on it (3 people working = 3 computers = 3 different paths that it flops between).

[zajrik]

Currently having this issue myself. I can't believe this has been an open issue for 2 years. Any word on this?

[Gerrit0]

Could someone experiencing this provide a repo + doc generation script that reproduces the issue? I have been unable to reproduce this on the TypeDoc repo.

[zajrik]

For me, the issue is presenting itself when I run TypeDoc on a project containing a class that inherits from some class provided by an external library. The "Defined in..." section of all the inherited members on that class display the local file paths to the external library. Specifically, they're pointing to the Error definition in the node lib definitions file in the TypeScript folder within TypeDoc's node_modules itself if I recall correctly. I haven't poked around with it since I left work yesterday.

I was able to work around the issue for the current specific project I'm working on by not extending Error directly and simply manually capturing a stack trace.

But I know I'm also planning on writing another library module in this set of separate modules once I conclude this current module and it will have to explicitly inherit from an external library so this problem will present itself once again.

[zajrik]

I whipped up a quick repo where the issue is definitely occurring.

https://github.com/zajrik/typedoc-test

You can see in docs/classes/testerror.html that any of the "defined in" sections show a path to a local file, for example:

<aside class="tsd-sources">
	<p>Inherited from Error.message</p>
	<ul>
		<li>Defined in D:/Code Stuff/node-projects/sambo/docs-test/node_modules/typedoc/node_modules/typescript/lib/lib.es5.d.ts:974</li>
	</ul>
</aside>

This result can be reproduced with npm run docs or yarn docs if you prefer.

Is there something we're missing to allow us to exclude local file paths in the output? I don't mind having inherited members listed. I just don't want my filesystem information inserted into the documentation. Even if it's not necessarily compromising in any way, I just don't care to see it on there, especially since it provides no useful information for those without any way to actually see the file it points to.

[Gerrit0]

Thanks! This should definitely be fixable, not sure what's causing it yet, but I'll look into it.

[zajrik]

Awesome! Glad I could help. If you need anything else let me know. I'd really like to be able to use TypeDoc in the end for my multi-module project. Using JSDoc on the transpiled JS in my last big project really just isn't cutting it for me anymore. It's too clunky and I had to hack extra features into JSDoc and the theme I'm using just to satisfy how I wanted the documentation to be. TypeDoc provides all of the changes I made to JSDoc with the added benefit of supporting TS out of the box so no extra steps.

[Gerrit0]

Well, that was an... interesting debugging session. Apparently just using require('path').relative to define paths relative to the cwd isn't good enough... and we needed a custom algorithm with labeled for loops so that we can break out of inner loops to figure out the base path. base-path.ts.

Why? I have no idea. The issue is that all the code for a project generally lives under src/ or some such directory, and these are the only files that are passed to add in the above class... calling this.basePath.add(fileName); on line 112 in SourcePlugin.ts at least makes the file names relative to the project directory, but it doesn't feel like the right solution. I'll keep digging.