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

@link to exported member with declaration reference links to top of module #2810

Closed
aayla-secura opened this issue Dec 14, 2024 · 6 comments
Closed
Labels
bug Functionality does not match expectation

Comments

@aayla-secura
Copy link

Search terms

link, declaration references

Expected Behavior

I expect the link to point to the relevant object, class, etc regardless which resolution type is used.

Actual Behavior

When I link to an exported in another module using the declaration reference syntax (because the linked member is not imported by the file for example), the link points to the top/root module and not to the exported member.

Steps to reproduce the bug

For example, moduleA exports someVar, which in the doc has its own page.

If I import this into moduleB and use {@link someVar} it correctly links to it.

If I don't import it and use {@link moduleA!~someVar} it links to moduleA.

Relevant installed packages + versions

tsconfig.json

{
	"compilerOptions": {
		"target": "esnext",
		"module": "preserve",
		"moduleResolution": "node",
		"outDir": "./dist/types/",
		"declaration": true,
		"declarationMap": true,
		"emitDeclarationOnly": true,
		"isolatedModules": true,
		"forceConsistentCasingInFileNames": true,
		"strict": true,
		"noImplicitAny": true,
		"strictNullChecks": true,
		"strictFunctionTypes": true,
		"strictBindCallApply": true,
		"strictPropertyInitialization": true,
		"noImplicitThis": true,
		"useUnknownInCatchVariables": true,
		"alwaysStrict": true,
		"noImplicitReturns": true,
		"noFallthroughCasesInSwitch": true,
		"skipDefaultLibCheck": false,
		"skipLibCheck": false
	},
	"include": ["src/ts/"],
	"typedocOptions": {
		"entryPoints": [
			"src/ts/"
		],
		"entryPointStrategy": "expand",
		"out": "docs/",
		"plugin": ["typedoc-plugin-merge-modules"],
		"mergeModulesMergeMode": "module" // added by plugin typedoc-plugin-merge-modules
	}
}

How you are running TypeDoc + any relevant configuration files

npx typedoc

Environment

  • Typedoc version: 0.26.11
  • TypeScript version: 5.6.3
  • Node.js version: 20.18.0
  • OS: Ubuntu on WSL2 on Windows 11
@aayla-secura aayla-secura added the bug Functionality does not match expectation label Dec 14, 2024
@Gerrit0 Gerrit0 added the needs reproduction Needs a minimal reproducible case - https://gist.github.com/Rich-Harris/88c5fc2ac6dc941b22e7996af05d label Dec 14, 2024
@Gerrit0
Copy link
Collaborator

Gerrit0 commented Dec 14, 2024

Going to ask for a reproduction that I can easily clone for this one. I don't want to spend time guessing what your setup actually looks at.

Also, please try to reproduce without the plugin. Plugins can do things which will break link resolution.

@aayla-secura
Copy link
Author

Apologies, here is a minimal example that shows this: TypeStrong/typedoc-repros#48

The first link in the doc for index.bug that uses declaration references points to /modules/Module.html, while the second one points to /variables/Module.someVar.html. Is my declaration reference syntax incorrect?

@Gerrit0 Gerrit0 removed the needs reproduction Needs a minimal reproducible case - https://gist.github.com/Rich-Harris/88c5fc2ac6dc941b22e7996af05d label Dec 18, 2024
@Gerrit0
Copy link
Collaborator

Gerrit0 commented Dec 18, 2024

That's... interesting. I apparently missed the !~ case when implementing that parser some years ago. According to the tsdoc spec that should be a reference to a local of the module, which isn't something which TypeDoc supports as it only supports exports. TypeDoc should really be emitting an error here.

{@link Module!someVar} works

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Dec 18, 2024

... or maybe TypeDoc's docs should just be updated to describe how ~ actually works for it. Either way, this declaration reference doesn't parse correctly, so that's a bug.

// Resolve via "locals"... treat this as a stricter `.` which only supports traversing
// module/namespace exports since TypeDoc doesn't support documenting locals.
case "~":
if (
refl.kindOf(ReflectionKind.SomeModule | ReflectionKind.Project)
) {
high = children?.filter((r) => r.name === path.path) || [];
}
break;

@aayla-secura
Copy link
Author

Oh, I see where my original mistake was: I was trying to link to a property of an object (which seems to be impossible as they don't have their own anchor or page). And that's why I thought Module!object#prop was not working. Thank you for explaining.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Dec 18, 2024

TypeDoc does support one level of properties, though there was a bug prior to the most recent version where the links were resolved incorrectly.

shawninder pushed a commit to shawninder/typedoc that referenced this issue Jan 2, 2025
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