TypeScript
TypeScript copied to clipboard
Use absolute file paths in error messages
Search Terms
absolute
Suggestion
Output absolute paths in type errors for tsc
, or at least a way to specify this.
Use Cases
When type checking in monorepositories, typically tsc
is run for each workspace. tsc
is then run relative to the workspace it is run from, whereas developers are mostly interested in either the absolute path, or the path relative to the project root.
I have configured my terminal emulator so I can CTRL-click a file and then the file is opened in VSCode, even on the correct line. This works for tsc
output in simple TypeScript projects, because the file paths are relative to the project root. This also works for example for ESLint output, because it prints absolute paths. This does not work for tsc
in mono repositories, because the output of yarn workspaces run tsc
is relative to that workspace.
Examples
Clone and install a TypeScript mono repository.
git clone https://gitlab.com/remcohaszing/koas.git
cd koas
yarn
Let’s open the project using VSCode, since its builtin terminal is preconfigured to work with CTRL-click.
Run yarn workspaces run tsc
in the VSCode terminal. This should work fine.
Now mess up any type. I changed an instance of koas.Middleware
to koas.Middlewar
in packages/koas-core/src/index.ts
.
Run yarn workspaces run tsc
in the VSCode terminal again. Now this outputs an error and a file path. The file path is not clickable, because it can’t be resolved.
Checklist
My suggestion meets these guidelines:
- [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [x] This wouldn't change the runtime behavior of existing JavaScript code
- [x] This could be implemented without emitting different JS based on the types of the expressions
- [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
- [x] This feature would agree with the rest of TypeScript's Design Goals.
I work with monorepos and vscode almost exclusively. I can never click to navigate to the errored file directly when working with TypeScript. This option would help productivity in my and similar use-cases.
This would be a fantastic change for anyone working with monorepos.
This is issue that exhibits for monorepos in IDEs, however also automatic recognition of file errors in GitHub Actions. Having the ability to switch to absolute paths... Either by default, through TSConfig, or through environment variable, would be great thing.
Super Thumbs up! I have a large mono repo using yarn3 and if there is an error in src/index.ts, clicking on it in vsCode just gives me a list of all the src/index.ts files in all the packages or takes me to the src/index.ts if that exists in the root package. Neither of these are great and being able to click from a list of compile errors to the files where the errors occur improves development velocity substantially.
In a perfect world, tsc check the composite field in the tsconfig and if it is there, build a relative path back to the root (tsconfig without a composite field).
This is issue that exhibits for monorepos in IDEs, however also automatic recognition of file errors in GitHub Actions. Having the ability to switch to absolute paths... Either by default, through TSConfig, or through environment variable, would be great thing.
Yep, came here for this. The default problem matcher instrumented by https://github.com/actions/setup-node does not know how to show proper annotations since the paths are relative.
If anyone is looking for a hack to get things working in GitHub actions:
tsc --pretty false | sed -E "s#^.+\(.+\): error TS.+\$#$PWD/\0#"
It just prepends $PWD to lines formatted like errors.
It looks like this was actually the previous behavior of TSC at some point, interestingly enough: https://github.com/microsoft/TypeScript/issues/7238
Agree that having this as an option would make using tsc with monorepos much easier.
As far as I can tell, the main thing that would need to change is
https://github.com/microsoft/TypeScript/blob/d8e81bbf6e6614bab7a0c5fba1e88a173943d22d/src/compiler/program.ts#L659
and
https://github.com/microsoft/TypeScript/blob/d8e81bbf6e6614bab7a0c5fba1e88a173943d22d/src/compiler/watch.ts#L356
In order to support absolute path outputs in build and watch mode.
FYI: Combining pipe-if-ci with reviewdog will work around the issue of GitHub Annotations not displaying. I think this will help you.
- More info: https://github.com/mizdra/node-pipe-if-ci#use-cases-github-annotations
I've got my own, similar, wrapper script to tsc
that we're using at our organization as a workaround. However, it's becoming such a common use case that I would love it if the Typescript team could weigh in here. Previously, the team's position was that they did not plan to allow for an additional option for absolute path output from tsc
.
Given it has been almost 7 years since that issue was closed and JavaScript development practices & tooling have undergone a significant shift towards monorepo-style development patterns, I would love to see this decision revisited.
Other ideas to solve the problem:
How about outputting relative paths that are hyperlinked to absolute paths instead of absolute paths? That is, have tsc output logs like this
$ printf '\e]8;;file:///Users/mizdra/src/github.com/mizdra/eslint-interactive/src/index.ts\e\src/index.ts\e]8;;\e\e]8;;\e\e\e]n'
https://user-images.githubusercontent.com/9639995/220143165-5147572d-caf7-4c2d-94ac-389dc5d10342.mov
Many modern terminals seem to support this feature.
- https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
I think this approach would provide clickable paths without annoying the user with the length of the paths output.
I have also though about this. At first this seems like the way to go (for any CLI tool that outputs file paths). However, TypeScript doesn’t just output file paths. It outputs path:line:column
. E.g. ../index.ts:123:42
. Various tools, such as VSCode, can handle this format to open text files on the specified line and column.
The primary use-case for myself and several other users in this thread is having support for Github Actions' problemMatcher functionality, which uses a regex to extract error file paths, severity levels, and messages from CI runs and display them inline in Pull Request diffs. Extracted file paths must either be absolute, or relative to where the root of the repository is checked out within the CI environment.
The link solution @mizdra suggested is an elegant solution for the local development, but most likely would not work in a portable or intuitive way with CI (for example, you'd probably have to write your own forked problemMatcher regex for filepath extraction rather than just being able to leverage the built-in functionality from actions/setup-node
, and even that assumes that the problemMatchers run on console output before it's been stripped of escape sequences).
Adding absolute path output in tsc error messages, combined with the work I've done in [email protected] to enable unprefixed output, would give tsc
users automatic error recognition when tsc
is used within a Github Actions workflow in a yarn monorepo.
Another possibility would be to add mono-repo to TypeScript itself. If it’s possible to type check multiple projects in one command, not only could TypeScript print relative paths properly, but it could share the document registry internally, which would enhance a performance. E.g.:
tsc --project './packages/*' --project './examples/*'
I've released a very simple drop-in replacement tsc wrapper, tsc-absolute, that fixes this problem. It's potentially preferable to other solutions (e.g. piping through awk/sed) as it generally keeps your npm scripts simpler, is portable across platforms, and ensures things like exit codes and signals are handled correctly. To install, it's as simple as:
- Run
npm install --save-dev tsc-absolute
. - Replace
tsc
withtsc-absolute
in your scripts.
This is really useful in monorepo setups for developer experience. It allows you to click to files in the terminal reliably, as well as match on filenames in CI.
The README also includes a recommended GitHub problem matcher configuration, that I think catches the logs better (and supports the kinds of logs generated by monorepo tools like npm workspaces / yarn / nx / turborepo).
Would a contribution for this change be accepted or are there considerations that have been not addressed?
This isn’t really a problem when you use project references, which you should when dealing with mono repos.
This isn’t really a problem when you use project references, which you should when dealing with mono repos.
This isn't helping for our projects, for example. We are using Rush.js, the Microsoft's monorepo management tool, and each project within a monorepo has its own tsconfig. Then this issue becomes really visible.
I've created a patch-package to display the full path:
diff --git a/node_modules/typescript/lib/tsc.js b/node_modules/typescript/lib/tsc.js
index f4e4fed..ea8bf64 100644
--- a/node_modules/typescript/lib/tsc.js
+++ b/node_modules/typescript/lib/tsc.js
@@ -5675,7 +5675,7 @@ function getRelativePathFromDirectory(fromDirectory, to, getCanonicalFileNameOrI
return getPathFromPathComponents(pathComponents2);
}
function convertToRelativePath(absoluteOrRelativePath, basePath, getCanonicalFileName) {
- return !isRootedDiskPath(absoluteOrRelativePath) ? absoluteOrRelativePath : getRelativePathToDirectoryOrUrl(
+ return !isRootedDiskPath(absoluteOrRelativePath) ? absoluteOrRelativePath : basePath+"/"+getRelativePathToDirectoryOrUrl(
basePath,
absoluteOrRelativePath,
basePath,