We Keep Coding

Laravel Mix HMR Server Does Not Launch

Laravel Mix Version: 6.0.43
Node Version (node -v): 16.13.1
NPM Version (npm -v): 8.1.2
OS: Windows 10 21h2
Description:
THIS IS HAPPENING ON A FRESH NEW INSTALL OF LARAVEL AND MY OTHER PROJECTS
Running npm run hot changes the script tag sources to http://localhost:8080/*/*.* from http://localhost/*/*.* HOWEVER I always get net::ERR_EMPTY_RESPONSE from localhost:8080. The HMR server doesn't launch at all. The terminal output of the command also have no mention of spinning up a new web server.
PS C:\Users\Eric Wang\Documents\GitHub\test-laravel-mix> npm run hot
● Mix █████████████████████████ emitting (95%)
emit
● Mix █████████████████████████ done (99%) plugins
WebpackBar:done
✔ Mix
Compiled successfully in 5.51s
Laravel Mix v6.0.43
✔ Compiled Successfully in 5336ms
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬──────────┐├────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼──────────┤│ css/app.css │ 47.6 KiB │└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴──────────┘webpack compiled successfully
Here's a picture of the browser failing to fetch the bundle files
Steps To Reproduce:
I am running Docker 4.5.1 using legacy Hyper-V.
I containerized Laravel and PHP BUT not the frontend and JS. I am running Laravel Mix on my main system.
Clone the fresh installation of Laravel from https://github.com/ericwang401/test-laravel-mix
Clone Laradock in the project folder using git clone https://github.com/laradock/laradock.git
CD to the Laradock folder and make .env file with cp .env.example .env
Inside .env file set PHP_VERSION to PHP_VERSION=8.0 AND DO NOT EDIT MYSQL SETTINGS
Now edit the Laravel environment file
DB_CONNECTION=mysql
DB_HOST=mysql
DB_PORT=3306
DB_DATABASE=default
DB_USERNAME=default
DB_PASSWORD=secret
Start up the Laravel app in Laradock folder using docker-compose up -d nginx mysql
Enter into bash mode in the Docker container docker-compose exec workspace bash
Install Composer dependencies BUT NOT NPM DEPENDENCIES YET composer i
Now exit out of the Docker container CNTRL + D
Install NPM dependencies in project root ON YOUR MAIN SYSTEM npm i
Run on your main system npm run hot
Now go to http://localhost and IT SHOULD be a white screen
Check console logs and it should give net::ERR_EMPTY_RESPONSE when it tries to fetch the bundle files
REMEMBER: the backend is running inside Docker
The frontend (Laravel Mix) is running on the host system
This issue is happening on a FRESH project installation of Laravel 9 + Jetstream AND it's also happening on my other older projects like https://github.com/StratumPanel/Stratum-Panel
The HMR server is simply not launching.

I found out the issue. The problem was that the default port, 8080, Laravel Mix HMR was using couldn't be binded to. Webpack Dev Server doesn't respond with a message of failing to bind to a port. To confirm this issue, I replicated the environment on my friend's PC and it too couldn't bind to port 8080, but this time it reported an error that the dev server couldn't bind to port 8080.
I fixed this issue by specifying
mix.options({
hmrOptions: {
host: 'localhost',
port: 4206
}
});
And it works! On both my friend's pc and my pc.
I used the exact same reproduction instructions on my friend's PC.
I spent way too long investigating this issue 😭

how to resolve conflict of webpack in specific port (vue.js)

I use npm webpack in vue.js project.
npm run dev
In webpack.dev.conf.js, I use proxy table.
proxy: {
"/api": {
target:"http://localhost:5000",
changeOrigin: true
}
},
It worked well, but now I can't.
Once I changed proxy url to https://my-domain.com, and it never works.
I rolled back to "http://localhost:5000", but error message says proxy can't access to https://my-domain.com.
For reference, I ran it again(npm run dev) whenever I changed it.
And it doesn't work at 8080 port, but it works well at 8082 port. How can I resolve conflict of webpack for specific port?

Vue invalid host header

Don't know why 2 days ago my projects ( created via vue create ) stopped working - in Chrome i get
Invalid Host Header
and
WDS Disconnected
errors. In cmd everything compiles properly( npm run serve )
I don't know webpack, so i have no idea how to fix it.
What i've already done:
reinstalled node
deleted and reinstalled all npm packages

This issue is caused by this webpack-dev-server issue that has been fixed recently.
To avoid getting the Invalid Host/Origin header error add this to your devServer entry on vue.config.js file:
disableHostCheck: true

Note that disableHostCheck: true is not recommended because it creates security vulnerabilities.
For a dev server running on my local machine, I could resolve the issue by explicitly setting --host in vue-cli-service serve:
scripts: {
serve: "vue-cli-service serve --host myapp.localhost"
}
The --host option is documented here.
Visit the app in your browser under myapp.localhost:8080 (assuming you're using default port 8080).

Found this question searching for the same "Invalid Host Header" issue. Here's how I solved it.
I am running Vue dev server npm run serve in Docker on my remote server. Couldn't access it at http://example.com:8080 with the error message above.
Correct and secure way is to add the domain name to the vue.config.js file:
"devServer": {
"public": "example.com"
}
This is a fresh vue project initiated with Vue Cli command: vue create myproject with Vuetify added via vue add vuetify. Full content of my vue.config.js after that is:
module.exports = {
"transpileDependencies": [
"vuetify"
],
"devServer": {
"public": "example.com"
}
}

This is because of the dev server which isn't accepting external requests. To solve this, we've to configure vue.config.js as below.
If vue.config.js is not found in your vue project, please create the file in root directory and add the following line.
module.exports = {
// options...
devServer: {
disableHostCheck: true
}
}
Source

Is it necessary to use Forever.js on OpenShift?

I've deployed my first Node.js app on OpenShift's free tier, and it works great.
Will OpenShift automatically restart my Node app when it crashes, or do I have to set up Forever.js? I tried setting it up, and it would not work. After running node_modules/forever/bin/forever start app.js (working dir was app-root/repo, with local copy of forever) I got this output:
warn: --minUptime not set. Defaulting to: 1000ms
warn: --spinSleepTime not set. Your script will exit if it does not stay up for at least 1000ms
info: Forever processing file: app.js
fs.js:240
return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
^
Error: ENOENT, no such file or directory '/var/lib/openshift/5397416f5004466c0b000080/.forever/VQMF.log'
at Object.openSync (fs.js:240:18)
at Object.startDaemon (/var/lib/openshift/5397416f5004466c0b000080/app-root/runtime/repo/node_modules/forever/lib/forever.js:406:14)
at /var/lib/openshift/5397416f5004466c0b000080/app-root/runtime/repo/node_modules/forever/lib/forever/cli.js:258:13
at /var/lib/openshift/5397416f5004466c0b000080/app-root/runtime/repo/node_modules/forever/lib/forever/cli.js:145:5
at Object.oncomplete (/var/lib/openshift/5397416f5004466c0b000080/app-root/runtime/repo/node_modules/forever/lib/forever.js:358:11)
So, does OpenShift manage my app's health for me, or will I need to get Forever working? If so, any idea as to the error I got?

Yes, OpenShift does automatically restart your Node app when it crashes. OpenShift doesn't use forever.js but it uses node-supervisor. Your can test it by requiring something that doesn't exist. Fix it quick though because the log can grow fast restarting the app. Here is the log in nodejs.log on OpenShift which shows that it's running node-supervisor:
DEBUG: Running node-supervisor with
DEBUG: program 'server.js'
DEBUG: --watch '/var/lib/openshift/53a9e06ae0b8cde26300008e/app-root/data/.nodewatch'
DEBUG: --ignore 'undefined'
DEBUG: --extensions 'node|js|coffee'
DEBUG: --exec 'node'
DEBUG: Starting child process with 'node server.js'
DEBUG: Watching directory '/var/lib/openshift/53a9e06ae0b8cde26300008e/app-root/data/.nodewatch' for changes.

Currently, OpenShift's default behavior involves using supervisor to start, watch, and restart your nodejs applications.
Here is a quick outline of the various init options for nodejs:
If your app includes a valid package.json file with a main entry (containing the name of your server script), then OpenShift will initialize your app by using supervisor to start that script.
If your app includes the force_npm_deploy marker file (an empty file in .openshift/markers/use_npm) - then OpenShift will just run npm start. This runs whatever is defined in your package.json file's scripts.start entity.
If all else fails, OpenShift will try to run server.js using supervisor (as a fallback option).
Some additional notes are available here: https://www.openshift.com/blogs/10-reasons-openshift-is-the-best-place-to-host-your-nodejs-app#npm

Express package still "require"-able after npm uninstall?

npm uninstall express successfully uninstalls express, and when I ls $NODE_PATH, it isn't there anymore.
However, if I run node and require('express'), I get
{ version: '1.0.0rc2',
Server: { [Function: Server] super_: { [Function: Server] super_: [Object] } },
createServer: [Function] }
Why does this still happen?
The reason I'm playing around with Express is because (apparently) it breaks with a certain version of Connect. Does anyone know what successful combination of Express and Connect will work ?
Thanks!

Output the require paths console.log(require.paths)
Those are the paths nodejs is using to resolve the require('express')

Try npm config get root—that shows you where npm is installing things. If it's pointing somewhere that doesn't make sense, use npm config set root [new path] to change it to something that's in Node's require.paths. (Of course, now you'll have to reinstall all of your npm packages.)

I currently use latest node, Express#1.0.8, Connect#0.5.10. I've been having some issues with upgrading to the latest connect/express, so I vowed to finish building my app first and then perform a massive upgrade. This combo works well for me though.