Skip to content

Target files on different drive than the output path cause invalid path and error is thrown #12759

Description

@JonWallsten

Bug report

What is the current behavior?
When providing assets from a different drive than then output path on Windows Compiler.js throws an error and the build fails.

mkdirp(fs, dir, writeOut);

// Running this code generates the output below
if (targetFile.match(/\/|\\/)) {
	const fs = this.outputFileSystem;
	console.error('[Compiler.js] Output path: ', outputPath);
	console.error('[Compiler.js] Target file: ', targetFile);
	const dir = dirname(fs, join(fs, outputPath, targetFile));
	console.error('[Compiler.js] Dir: ', dir);
	mkdirp(fs, dir, writeOut);
}
// Output:
[Compiler.js] Output path:  C:\Users\RUNNER~1\AppData\Local\Temp\_karma_webpack_191749
[Compiler.js] Target file:  D:\a\ts-loader\ts-loader\test\execution-tests\3.0.1_projectReferences\lib\tsconfig.tsbuildinfo
[Compiler.js] Dir:  C:\Users\RUNNER~1\AppData\Local\Temp\_karma_webpack_191749\D:\a\ts-loader\ts-loader\test\execution-tests\3.0.1_projectReferences\lib
{ [Error: EINVAL: invalid argument, mkdir 'C:\Users\RUNNER~1\AppData\Local\Temp\_karma_webpack_191749\D:\a\ts-loader\ts-loader\test\execution-tests\3.0.1_projectReferences\lib']
  errno: -4071,
  code: 'EINVAL',
  syscall: 'mkdir',
  path:
   'C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\_karma_webpack_191749\\D:\\a\\ts-loader\\ts-loader\\test\\execution-tests\\3.0.1_projectReferences\\lib' } ```

A path with multiple drives doesn't seem to be valid on Windows. So just joining the two paths doesn't work.

If the current behavior is a bug, please provide the steps to reproduce.
This only happens when testing ts-loader with Github Workflow (seems to be running Microsoft Windows Server 2019), I've been unable to reproduce on two local Windows 10 machines. So it's hard to give steps to reproduce. But happens every time we run the test suite on Github:
https://github.com/TypeStrong/ts-loader/runs/1958905766?check_suite_focus=true

I do have a webpack fork as dependency for a ts-loader fork where I can reproduce this. That's how I got the log statements and the stack trace leading to Compiler.js.

What is the expected behavior?
When providing an asset located on another drive than the output path it should not crash.

Other relevant information:
webpack version: 5.20.0
Node.js version: 10.x.x/12.x.x/14.x.x
Operating System: Microsoft Windows Server 2019
Additional tools:

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions