ENOENT upon npm watch

[denydias]

Hi! Thanks for your wonderful HydePHP!

I'm facing an issue while Managing and Compiling Assets. When developing with npm run watch, although it runs successfully on the first time, as soon as I change something at resources/assets/app.js, it fails with:

[webpack-cli] [Error: ENOENT: no such file or directory, unlink '/path/to/hyde/_site/media/mix-manifest.json'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'unlink',
  path: '/path/to/hyde/_site/media/mix-manifest.json'
}

I've tried many variations to setPublicPath('_media') in webpack.mix.js with no luck. Am I missing something?

Thanks in advance for any reply.

[denydias]

As a workaround, I did this to exclude mix-manifest.json:

mix.js('resources/assets/app.js', 'app.js')
    .postCss('resources/assets/app.css', 'app.css', [
        require('tailwindcss'),
        require('autoprefixer'),
    ]).setPublicPath('_media')
    .copyDirectory('_media/!(*.json)', '_site/media'); // exclude *.json

[caendesilva]

Hey I am so sorry I missed this! Thank you so much for the kind words! It's getting late where I am, so I will take a closer look at this tomorrow. Usually ENOENT errors means that WebPack failed to do a filesystem operation, usually this is when trying to remove a file that does not exist (either because it never existed in the first place, or it was already removed). Since Hyde clears the output directory on each build, that could have something to do with it. I will try to repro the issue tomorrow.

[caendesilva]

Hey again @denydias! I know this might be annoying, but if you could answer some questions that would help me a lot in trying to reproduce and debug this issue. If you don't understand any of the questions that's okay, it probably means the answer is "no" and that is still helpful.

1. Have you modified any source/output directory configurations? (I'm assuming you haven't, based on your supplied code, but just want to double check)
2. Does the error occur immediately when running the command, after doing something else (like running the build command, visiting a page served from the realtime compiler, or modifying a source or asset file), or is it seemingly random? Edit: See note below
3. What operating system family are you running?
4. What version of Hyde are you running? You can find this out by running the php hyde debug command, or preferably paste the output of the following command composer show hyde/*.
5. If you manually create a file at _site/media/mix-manifest.json, do you still experience this?

Edit: Whoops, I missed that you specified this happens when you edit app.js. If you see this before I've had the chance to write anything else, please answer the non-striked questions if you can, while I try to reproduce.

[caendesilva]

Okay I have managed to reproduce this. Running the mix command on a fresh project with no site builds works fine as described in the original issue, modifying app.js gives an ENOENT. However, if the _site/media directory exists, it runs fine. As a sidenote to myself, if I save the file twice I get an EBUSY as the resource is locked, but that is probably unrelated but similar.

@denydias if you run mkdir _site/media (or the system equivalent), and then run the steps again, do you still get this error?

[denydias]

Sure, @caendesilva! My pleasure to help you debug that!

1. Have you modified any source/output directory configurations? (I'm assuming you haven't, based on your supplied code, but just want to double check)

Nope.

3. What operating system family are you running?

Slackware Linux -current (post 15)

4. What version of Hyde are you running? You can find this out by running the php hyde debug command, or preferably paste the output of the following command composer show hyde/*.

$> composer show hyde/*
hyde/framework         v1.1.1 The HydePHP Framework
hyde/realtime-compiler v3.0.0 HydePHP Realtime Compiler Server

5. If you manually create a file at _site/media/mix-manifest.json, do you still experience this?

Yes. Mix deletes it before copy the new one, and that's where it hangs.

[denydias]

@denydias if you run mkdir _site/media (or the system equivalent), and then run the steps again, do you still get this error?

Sometimes. It looks like a race condition when updating (rm/cp in mix parlance) _site/media contents.

[caendesilva]

@denydias Thanks so much for the debug information. I also think this has something to do with a race condition. I'm gonna rubber ducky a bit here, since that's how I work. You can pretty much ignore the rest of this post as I am mainly just thinking out loud here.

The question now is who's fault this is, if it's something in the PHP code, or if I misconfigured something with Laravel Mix. Since the PHP stuff in Hyde only touches the output directory upon site builds I would bet this issue resides in the NodeJS land.

So what I'm going to try to do is to narrow down where the root cause of issue could be. Since I could reproduce on my Windows machine, and you are on Linux, it doesn't have anything to do with the OS. I'll also talk around with people more experienced with Webpack to see if they have any ideas. Tomorrow I'm going to scale down the repro setup and try this without any other stuff in the way.

I'm thinking that since the issue seems to be when trying to unlink a file that doesn't exist, Webpack errors. But in my opinion I actually don't care about that. If I want a file removed, I want it gone. If it was already removed, that's a win in my book, so there might be some configuration option to suppress this "error".

Edit:

Creating a repro repo for this, and noticed that this is not tied to the app.js. I got the ENOENT when deleting a .gitkeep file. So I think this happens any time Webpack is triggered by a filesystem change. This also happened when I was sure the manifest file already existed, so it seems like Mix tries to run the unlink command twice. Maybe by first removing the entire directory? Or it's a race condition between multithreaded processes which would explain it not happening every time.

[denydias]

Thank you so much for your prompt and interested responses, @caendesilva! HydePHP is indeed a great project and holds the potential to carry a revolution in static site generators front on PHP/Laravel realm.

As I managed to get a workaround I'll just watch from here, but count on me if you need any extra information on this issue.

[caendesilva]

Thank you so much yourself @denydias! I really appreciate the help and the encouraging words!! If you run into any new problems, let me know any time and I'm happy to help.

[caendesilva]

Found a related upstream issue. Hotpatch seems to work. PR-ing a fix soon. laravel-mix/laravel-mix#1326 (comment)

[caendesilva]

This issue was fixed upstream in hydephp/develop#1376, but I'll keep the issue open until it makes its way down here too. I'll probably cherry pick it into a patch release once the CI is done working.

[caendesilva]

Fixed in #226! Sorry for the late release!

[denydias]

Thank you so much, @caendesilva!