webpack-plugin-serve: ramdisk throws "no such file or directory, symlink ..." if webpack `output.path` is specified

Not sure if this is an upstream issue in webpack-plugin-ramdisk or an issue here.

Webpack Version: 4.9.1
Operating System (or Browser): macOS High Sierra 10.13.6
Node Version: 10.16.0
webpack-plugin-serve Version: 0.12.0

How Do We Reproduce?

Literally just setting ramdisk: true

Expected Behavior

Builds and serves content same as when ramdisk isn’t set, but faster (and not output to disk).

Actual Behavior

⬡ wps: Ramdisk enabled
⬡ webpack-plugin-ramdisk: Build being written to /Volumes/wps/49d4ada5043fbb2f01d098d183664fc2/build
...

Error: ENOENT: no such file or directory, symlink '/Volumes/wps/49d4ada5043fbb2f01d098d183664fc2/build' -> '/path-to-my-project-dir/build/'
    at symlinkSync (fs.js:909:3)
    at WebpackPluginServe.init (/path-to-my-project-dir/node_modules/webpack-plugin-serve/lib/plugins/ramdisk.js:83:5)
    ...

It does delete the build directory before it errors out. ls /Volumes/wps/ shows nothing, ls -a shows a .fseventsd directory.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 26 (23 by maintainers)

Most upvoted comments

Yeah this isn’t low hanging fruit and will take a lot more investment of time. Replying to issues is pretty cheap in that regard. We’ll get to it, just going to be a while.

shellscape on Feb 27, 2020

So I spent a few hours on the original problem in this issue and came up empty. Given the age of the issue and that the maintainers have been unable to reproduce reliably locally, we’re going to have to close this one. That said, we’re totally open to a PR in either this plugin or the webpack-plugin-ramdisk plugin.

shellscape on Nov 28, 2020

I’ve just realised that the problem was slightly different to what I initially thought, and that commit 14d2af48b93bec08d63a95d2f9c4d4ab1f01ca63 fixes the problem I’ve been having. Specifically, I don’t have publicPath set in my config, and that commit fixes this case. So with version 1.0.1 (which includes this fix) everything is fine on my end.

I believe my problem was different to the issue @agilgur5 reported.

peterkelly on Jun 19, 2020

Looks like it’s caused by 3ca6e830eac93525bbed9142fa76e991caee967b. I have a config that uses output.path and when I comment out the changes in that commit it works.

peterkelly on May 25, 2020