I have a Vue project generated by the Vue cli 3 and my hot reloading suddenly stopped working in my browsers. Changes made to the code are still picked up by the terminal, however, my browser is not picking up the changes. I have to manually refresh in order to pick up the new changes. As suggested by some others I manually set poll: true in my vue.config.js and I also tried to set the proxy, but both had no success.
Any suggestions to make this work again?
Update:
After some Vue updates, it suddenly started working again. I still don't know the reason for this. It might have been a bug in the vue-cli?
My problem was WDS
Console displayed:
[HMR] Waiting for update signal from WDS...
[WDS] Disconnected!
GET http://ip:port/sockjs-node/info?t=some-number
net::ERR_CONNECTION_TIMED_OUT sockjs.js?some-number
Solution for me was:
in
package.json
change
"serve": "vue-cli-service serve",
to
"serve": "vue-cli-service serve --host localhost",
or
add
module.exports = {
devServer: {
host: 'localhost'
}
}
to
vue.config.js
:)
HMR has problems in various environments, in those situations you can maybe help yourself with the poll option:
https://github.com/vuejs-templates/webpack/blob/develop/template/config/index.js#L21
var devMiddleware = require('webpack-dev-middleware')(compiler, {
publicPath: webpackConfig.output.publicPath,
stats: {
colors: true,
chunks: false
},
watchOptions: {
aggregateTimeout: 300,
poll: 1000
}
})
Seems I finally found it: my $cat /proc/sys/fs/inotify/max_user_watches was on 8192 and this helped me:
echo 100000 | sudo tee /proc/sys/fs/inotify/max_user_watches
Now Vue hot reload works without sudo and without poll ! ))))
One failure mode I've come across here is if you've managed to end up with multiple installations of webpack in your node_modules.
The reload relies on these two bits of code emitting events to each other:
webpack-dev-server/client/index.js
var hotEmitter = require('webpack/hot/emitter');
hotEmitter.emit('webpackHotUpdate', currentHash);
webpack/hot/dev-server.js
var hotEmitter = require("./emitter");
hotEmitter.on("webpackHotUpdate", function(currentHash) {
However, if you have multiple webpacks installed (e.g. a top-level one and one under #vue/cli-service) the require will resolve the first to ./node_modules/webpack/hot/emitter.js and the second to ./node_modules/#vue/cli-service/node_modules/webpack/hot/emitter.js which aren't the same object and so the listener never gets the event and reloads fail.
To resolve this I just uninstalled and reinstalled #vue/cli-service which seemed to clear the package-lock.json and resolve to the single top-level webpack.
I don't know if there's any way to ensure this doesn't happen -- however, it might be possible for vue-cli-3 to spot the situation and at least log a warning in dev mode?
[BTW adding devServer: { clientLogLevel: 'info' } } to vue.config.js was really helpful in debugging this.]
I faced the same issue (the console showed an error that said "[WDS] Disconnected") and here's what I did. Note that I was using the Vue UI tool for managing my project and I did not edit any config files.
Under Tasks/serve, I stopped the task.
I clicked the parameters button and in the input for "Specify host" label, I added the IP of my localhost i.e. 127.0.0.1 and in the input for "Specify port" label, I added 8080.
I saved the parameters and ran the server again from the tool.
Not sure why but this seemed to work for me. I'd love if someone can explain why it works.
I also have this WDS issue with each Vue project I make (kind of annoying, even with latest vue cli 4.5.0 and vue 2.6.11).
So the following solution is what I copy paste each and every time.
In vue.config.js file :
module.exports = {
devServer: {
// Fixing issue with WDS disconnected and sockjs network error
host: '0.0.0.0',
public: '0.0.0.0:8080',
disableHostCheck: true,
// End of fix
}
}
What was the cause in my case:
It seems that the value of: max_user_watches
in the /proc/sys/fs/inotify/max_user_watches
is affecting webpack => which is interfering with hot reloading.
To check your actual value
$cat /proc/sys/fs/inotify/max_user_watches
16384
16384 was in my case and it still wasnt enough.
I tried different type of solutions like:
$ echo fs.inotify.max_user_watches=100000 | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -p
But it seems that even if I changed the value, when I restarted my PC it would go back to default one 16384.
SOLUTION if you have Linux OS(my case, I have Manjaro):
Create the file:
sudo nano /etc/sysctl.d/90-override.conf
And populate it with:
fs.inotify.max_user_watches=200000
It seems 200000 is enough for me.
After you create the file and add the value, just restart the PC and you should be ok.
Maybe this can help https://webpack.js.org/configuration/watch/#changes-seen-but-not-processed
"Verify that you have enough available watchers in your system. If this value is too low, the file watcher in Webpack won't recognize the changes:"
cat /proc/sys/fs/inotify/max_user_watches
"On macOS, folders can get corrupted in certain scenarios. See this article."
And in the link above you can check other known issues.
set NODE_ENV=development might solve your problem.
Adding NODE_ENV=development to your .env file will solve the problem.
I hope that this could be helping someone, I'd used of the terminal in my WebStorm and vue-cli-service didn't work, then I opened a normal terminal and that's it, maybe something in WebStorm didn't let the correct way in the vue-cli-service
I used proxy extension in my Firefox browser. Try turning that off if you have one
Please make sure you don't have any error in your code.
This happens usually because of error in any of our code files.
Just run
npm install -g #vue/cli-init
You can run vue-cli-service serve --public localhost
According the docs:
--public specify the public network URL for the HMR client
https://cli.vuejs.org/guide/cli-service.html#vue-cli-service-serve
This was my problem anyway, HMR was running on the network IP instead, for some reason. Causing CORS and connection refused issues.
For me More Tools >> Clear Browsing data in Chrome did the trick. Also try incognito before.
In Firefox everything was fine.
So before editing your vue.config.js take a look at the browsers.
I solved this problem by changing the versions of my dependencies and devDependencies:
"dependencies": {
"core-js": "^3.4.4",
"vue": "^2.6.10",
},
"devDependencies": {
"#vue/cli-plugin-babel": "~4.1.0",
"#vue/cli-plugin-eslint": "~4.1.0",
"#vue/cli-service": "~4.1.0",
"babel-eslint": "^10.0.3",
"eslint": "^5.16.0",
"eslint-plugin-vue": "^5.0.0",
"vue-template-compiler": "^2.6.10"
},
Related
I'm trying to create a SVG component.
I have this problem after run command "npm i".
I think versions between packages aren't compatible.
How to fix this or create SVG component without react-native-svg package?
Thank a lot.enter image description here
Add the following to package.json:
{
// scripts, dependencies, etc.
"resolutions": {
"css-what": "5.0.1"
},
}
Remove lock file. Install the packages. Check if the app is still working. If works then keep the configuration (and ignore the warnings) else revert it.
Since you are using npm, you may wanna first refer this thread: npm equivalent of yarn resolutions?
I created a new angular project and ran the following command:
ng add #spartacus/schematics --baseUrl https://spartacus-demo.eastus.cloudapp.azure.com:8443/ --baseSite=electronics-spa --ssr. After, I ran the command npm run dev:ssr, opened http://localhost:4200 and found the following problem:
Any ideas how to correct this bug and make the app run SSR instead of CSR? This warning message is showing for every route I try to access.
(https://github.com/SAP/spartacus/issues/10638)
it's because of SSR optimization feature available in Spartacus 3.0 and up.
You can either extend the timeout in your server.ts (passing a second parameter to NgExpressEngineDecorator.get method) or set it to 0, so it won't be fallbacking to CSR at all. Here is an example:
const ngExpressEngine = NgExpressEngineDecorator.get(engine, { timeout: 0 });
You can use API documentation to get a list of available options:
https://sap.github.io/spartacus/interfaces/SsrOptimizationOptions.html
Additionally, an extended documentation regarding this feature is on its way and should be available soon.
I encountered same issue, but changing timeout does not help!
The root cause is: the certificate of Commerce Cloud is invalid, as it is self-assigned.
Because I am using local commerce, with URL: localhost://9002
And the workaround is:
Add below config to package.json
"scripts": {
"dev:ssr": "cross-env NODE_TLS_REJECT_UNAUTHORIZED=0 ng run mystore:serve-ssr",
},
[...]
"devDependencies": {
[...]
"cross-env": "^7.0.0"
}
Then run following to start Spartacus
yarn dev:ssr
This question already has answers here:
error NG6002: Appears in the NgModule.imports of AppModule, but could not be resolved to an NgModule class
(33 answers)
Closed 2 months ago.
ERROR in node_modules/#angular/common/http/http.d.ts:2801:22 - error NG6002: Appears in the NgModule.imports of AppModule, but could not be resolved to an NgModule class
2801 export declare class HttpClientModule {
restart your server...
terminate server for windows
ctrl + C
start again
ng serve
I had the same issue.
I was going through comments here https://github.com/angular/angular/issues/35399 for solution.
I simple ran ng serve --prodand the error was gone. After that I even ran ng serve.
Other solutions proposed are
Ensure that the tsconfig.json of your library has set "importHelpers": true
Add "enableIvy": false to compilerOptions in tsconfig.app.json
Adding "postinstall": "ngcc" to scripts: {...} in package.json then run npm run postinstall solved problem.
if you still want to keep the Anuglar Ivy and AOT advantage
Simply restart the server (press ctrl+c on the prompt) and then, run ng serve again.
I had the same issue. Then I realized that previously I've some changes in app.module.ts Every time you made changes in app.module.ts remember restart the server process.
I had the same issue. I was adding service to module i.e. app.module.ts's imports array instead of adding it to the providers array.
app.module.ts
#NgModule({
imports: [
MyService // wrong here
],
providers: [
MyService // should add here
]
})
export class EventsModule { }
For me I had a Pipe declared in my 'imports' in my module. Apparently many things can produce this error. I do not suggest you disable IVY, as that is not the problem.
Setting "aot": false inside angular.json file worked for me.
I terminated the current build and restarted it again.
i.e ng serve solved my error. Hope it helps.
In my case, I had included HttpClientModule run running the Angular server.
The below solution works best for my case
Just Close the Server, and reopen it.
It will work.
Working within an NX workspace I just came across this issue.
After a lot of searching I realised that the internal library that I just created had by default Ivy turned off.
I do have it on everywhere else. And yes, even for my libraries. They're only internal to the monorepo we don't expose any of them so we don't want to have an extra step to compile them with the deprecated view engine instructions and later on run ngcc onto it to turn that into Ivy code.
Conclusion: I just forgot to set
"angularCompilerOptions": {
"enableIvy": true
}
on my newly created library and the default is false which wasn't working in my case.
I had same issue in ubuntu. But when I used sudo bash command and executed ng serve. It resolve the issue
I had the same problem, it seems like there is a lot of ways to trigger the problem. I recommend trying to verify the .component, .module and the app.module declarations. Mine was triggered because I've declared the .component in app.module instead of the .module.
This happened to me in VSCode with another module after installing it with npm install. This is most likely related to how the Angular language service extension works and the quickest way to solve it was to restart the IDE.
this problem caused by angular extension and snippets in vscode
be careful not to install obsolete extensions like Angular Extension Pack and Angular Language Service
enter image description here
I've got an existing code base in which Vue.js has performance problems. I also see this notice in the browser console:
so I guess an easy fix could be to put Vue into production mode.
In the suggested link I try to follow the instructions for webpack. We're on Webpack version 2.7 (current stable version is 4.20). In the instructions it says that in Webpack 3 and earlier, you’ll need to use DefinePlugin:
var webpack = require('webpack')
module.exports = {
// ...
plugins: [
// ...
new webpack.DefinePlugin({
'process.env.NODE_ENV': JSON.stringify('production')
})
]
}
So in my package.json I've got a build script defined:
To build for production I run yarn run build and it runs a build.js file (paste here) which in turn calls webpack.base.conf.js (paste here) and webpack.prod.conf.js (paste here).
As you can see in the paste I use the DefinePlugin as suggested by the docs.
I also found a file called vue-loader.conf.js (paste here) and to be sure I also added the DefinePlugin in there as well.
I can run yarn run build which ends without errors, but when serve the site over Apache and open the browser it still shows the notification that we're in development mode.
To be sure it actually uses the files created by webpack I completely removed the folder /public/webpack/ and checked that the webinterface didn't load correctly without the missing files and then built again to see if it loaded correctly after the command finished. So it does actually use the files built by this webpack process. But Vue is actually not created in production mode.
What am I doing wrong here?
The problem may be in your 'webpack.base.conf.js' as i suspected, thank you for sharing it, upon searching i've found an issue resolving your 'production not being detected' problem on github here
The solution requires that you change 'vue$': 'vue/dist/vue' to 'vue$': vue/dist/vue.min in production.
You will find the original answer as:
#ozee31 This alias 'vue$': 'vue/dist/vue' cause the problem, use vue/dist/vue.min in production environment.
I'm attempting to use the spine.app cli and I'm encountering a couple of errors and I'm uncertain what the root cause actually is.
The guide found at: http://spinejs.com/docs/started gives these steps
spine app my-app
cd my-app
npm install .
hem server
following these steps, initially yields this error on the terminal:
Cannot find module: es5-shimify. Have you run `npm install .` ?
Investigating, it seems es5-shimify has been deprecated in favor of es5-shim, so my initial inclination was to replace the dependency to es5-shim. So I updated setup.coffee to require('es5-shim'), and I updated the referenced slug.json module and restarted the server. This seems to get me a little further, but still produces an error ( though not in the terminal, instead in the chrome console )
Uncaught TypeError: Property 'jQuery' of object [object Object] is not a function
This appears to be occurring on line 8 of public/index.html. I did some debugging here and it appears that require('jqueryify') is returning undefined, and I'm not certain what the expected result is. Any guidance on the right way to approach this process or perhaps information on what the root issue might be would be greatly appreciated.
Use the latest version try again.
The package.json as following
{
"name": "app",
"version": "0.0.1",
"dependencies": {
"spine": "~1.3.0"
}
}
all others dependencies has been removed,and it works for me.