Error messages use relative paths instead of absolute

[hesselink]

TypeScript Version:

1.8.2

Problem

I've found that somewhere between typescript 1.6.2 and 1.8.2, it started printing relative file names in error messages instead of absolute file names. This makes it harder for us to find the right (generated) input file, since we have to know what the paths are relative to. Was this change on purpose, or accidental? It's not listed in the change log.

[mhegazy]

it is intentional. they are relative to the current directory the compiler was executed in. this make it much easier for command line scenarios when you run tsc in a folder, instead of all errors having full folder path, it becomes much more user friendly.
How are you running tsc? VS? command line?

[hesselink]

We are running tsc from a custom build tool, which runs as a server watching the source directory for changes. So I guess for us it will be relative to whatever the working directory is for the build server, which is launched by another tool and runs in the background. The paths end up looking like ../../../build/some/generated/path/file.ts, which makes it hard to open them since you're not in the working directory and probably don't know what it is.

But I can see that this scenario isn't common, and that the relative paths are friendlier when used directly from the command line on non-generated source files.

[mikeyoon]

I noticed another side-effect of this change is that Webstorm will not link the file in the terminal since it expects absolute paths for its output filter macro.

[aychtang]

+1

It would be nice to have a compiler option to print absolute file paths of input files with errors for backwards compatibility.

This would involve adding a new compiler option and a dependant code branch in getCommonSourceDirectory() from src/compiler/program.ts.

[mhegazy]

New compiler options add complexity both for usage and for maintenance. i would punt on this issue for now unless there are new scenarios.

[hesselink]

That's too bad, since it means we'll have to:

• Carry state about the current working dir of typescript in our tooling.
• Parse the type script output.
• Rewrite the output to have absolute paths.

This will be a lot of finicky work that typescript could do much more easily. I do see the point about adding complexity in the compiler, just be aware that this shifts the complexity to some of your users.

[mredbishop]

This is also the same problem when running a tsc build task from VS Code. It's similar to webstorm in that the relative paths do not become links whereas previously, full-paths did. I agree with @aychtang that this should be a compiler option for backwards compatibility for the large number of people who've built their tool chains around the previous functionality.

[wgv-sethlivingston]

I also get the point about compiler complexity, but this forces us to jump through hoops to do something that we've been able to do for years and years: double click on an error to jump to the source line.

[ulrichb]

Please revisit this and add a "emit full paths" compiler option.

My situation: In a VS project I call gulp (with gulp-typescript) in a post-build action. The problem is that tsc emits the path in the error messages relative to the gulpfile, but VS expects them to be relative to the project dir. => I cannot double-click the error messages, unless I apply the following workaround in my gulpfile.

gulp.task("build",
    withChangedWorkingDir("dir/to/my/project", function () {
        var tsProject = ts.createProject("tsconfig.json");

        var tsResult = tsProject.src().pipe(ts(tsProject));

        return tsResult.js.pipe(gulp.dest("."));
    }));

function withChangedWorkingDir(path, callback) {
    return function () {
        var savedDir = process.cwd(path);
        process.chdir(path);
        try {
            callback();
        } finally {
            process.chdir(savedDir);
        }
    };
}

EDIT: The above workaround doesn't work when using a files-array in the tsconfig.json (tsc searches in the wrong directory). Instead, I configured a custom "reporter" for gulp-typescript.

[RyanCavanaugh]

I think you'd have to change gulp-typescript in that case -- it has access to the error message objects and only it can know what the "correct" relative filenames are

[ulrichb]

only it can know what the "correct" relative filenames are

I need full file paths (enabled by a compiler option) in all error messages, like it happens for paths outside of the rootDir (referenced by ///<reference...), resp. like it happened for all messages before 1.8 (see 884dff0),

Regarding change in gulp-typescript: yes, possible + in all the other tsc-wrappers where I need VS-compatible output, instead of a central option in tsconfig.json :/