I have a rather large Vue 3 application (~550 components). It takes two minutes just to run vue-cli-service serve and around 20 seconds to re-build it after each change. Hot reload stopped working a long time ago so it always needs to be refreshed in the browser even after a small style change. Moreover, the app is still not finished and it will probably get 2-3 times this big in the next year so it will probably be even worse.
Because of these problems, I've decided to migrate it from Vue CLI to Vite. I have already resolved a lot of problems and the app seems to work with Vite now with so much better loading times.
However, it sometimes gets stuck when I start a dev server (vite command) and open it in a browser. The page keeps loading and I can see a lot of pending requests in the Network tab of Chrome DevTools. There's nothing special in the output of vite --debug and running vite --force doesn't help either.
When this problem occurs, the browser always loads a lot of modules (~900) and then it gets stuck on 10-20 modules. The status of all these HTTP requests is simply Pending and they never finish. There are no errors in the browser or on the command line.
I don't think any particular file causes this. Maybe the problem is in my deeply nested folder structure with a lot of re-exports using index.ts file on each level. It mostly gets stuck on my own modules but I've also seen cases when it was waiting for a module of some external library.
Has anybody experienced a similar problem? How did you solve it?
EDIT: I have discovered that this issue only occurs in Chromium-based browsers (Google Chrome, Brave, etc.) on Linux. It works without any problems in Chrome on MacOS and Windows as well as in other browsers (Firefox, GNOME Web, etc.) on Linux.
Thanks to this comment, I realized this was a problem with the file descriptors limit.
On Manjaro Linux (Arch-based), I was able to solve it by adding the following line to both /etc/systemd/system.conf and /etc/systemd/user.conf file:
DefaultLimitNOFILE=65536
After this change, Vite works without any problems in all browsers.
Related
I have few queries related to the EOL of VueJS 2:
From Wiki link here:Vue.js - Wikipedia , I learn that Vue2 is having EOL in Sep 2023. Is this correct?
Where can we find the Last minor version of Vue2 i.e 2.7 as mentioned here ? If we will start using 2.7, how long it would help us to buy some time for migration to vue 3?
We have VueJS2 application and if we fail to migrate to Vue3 due to some reasons before EOL(using migration guide here: Introduction | Vue.js), What will be the impact?
Will we stop getting any security updates? OR Can we still expect critical security updates?
I hope we would still continue development using VueJs2 and npm install would continue to work for dev environment setup? Are there any chances of one or more dependency stop getting downloaded? (for example node sass etc?)
Are there chances that as the browsers will continue to update to the latest versions and cause some functionality in VueJS 2 stop working and we wouldn't be able to complaint since it’s already EOL?
I believe since no upgrade will happen to VueJS 2, we wouldn’t be able to expect any support for new features in browsers. Is it correct?
Your response will help us to understand and plan the things much in advance.
Will we stop getting any security updates? OR Can we still expect critical security updates?
EOL usually means the same thing on any ecosystem. It stops getting updates to allow moving on to the next thing. It'll still work but it's going to be just like that unless someone continues maintaining it in some way.
if we fail to migrate to Vue3 due to some reasons before EOL, What will be the impact?
You stop getting updates.
Vue component/libraries/plugin developers might write less Vue 2 code and more Vue 3.
If they wrote a Vue 2 code then use that. If there's none, you write one.
I hope we would still continue development using VueJs2 and npm install would continue to work for dev environment setup? Are there any chances of one or more dependency stop getting downloaded? (for example node sass etc?)
You can still continue working on it. It will install as long as it is still hosted on npm.
Are there chances that as the browsers will continue to update to the latest versions and cause some functionality in VueJS 2 stop working and we wouldn't be able to complaint since it’s already EOL?
I believe since no upgrade will happen to VueJS 2, we wouldn’t be able to expect any support for new features in browsers. Is it correct?
Vue is a library for rendering elements and I don't think it uses or ever will use any browser-specific code.
I'm having problems with cache on google chrome.
When I upload fresh code on production I still see the old version on the browser.
Usually pressing CTRL+F5 solved the problem, but nowadays it's not working.
The only solution I found is open the dev tools and check "disable cache", But I cannot use this for some teammates no computer-friendly... (CTRL+F5 was nice for this type of persons)
Why it's not working now? Google chrome did an update or something?
My educated guess (had a similar story while ago) is that your assets are rendered to the identical filenames. And because cache-control-max-age is set in the future, your assets are still seen by the browser as valid and fresh.
Disclaimer: I assume you use webpack or other capable module bundler
I would try appending some date-based suffix to your assets on build. That way it can be endlessly cached, and when new build is made - you get a new assets URL and the files are treated as a new entities, so cache-control has no influence on them.
I am attempting to run a test on our Electron app using TestCafe. I have tried many things but after many hours am still getting the error below:
"ERROR Unable to establish one or more of the specified browser
connections. This can be caused by network issues or remote device
failure."
The cases I have read Googling around do not seem to apply to my case.
I have everything set up as described here: https://github.com/DevExpress/testcafe-browser-provider-electron#testing-an-executable-electron-application
The .testcafe-electron-rc file is correct in that my app does indeed launch but errors as above. I do not think it gets to my script which is very simple for debugging purposes. I have tried changing the mainWindowUrlPath to various locations since it seems like my app is run from C:/Program Files/MyApp/resources/" which contains an app.asar file even though our app is located in "C:/Program Files/MyApp/MyApp.exe"
I have tried setting up the .testcafe-electron-rc in many configurations including the one described in the documentation as well as many others. An example is below which I realize is non-standard:
{
"mainWindowUrl": "C:/Program Files/MyApp/resources/app.asar/index.html",
"electronPath": "C:/Program Files/MyApp/MyApp.exe"
}
Note, I have never seen the index.html anywhere in the app directory but assume that TestCafe must dive into the asar in some manner.
I have disabled the Windows firewall but still, the same issue exists.
I have run my tests with nodejs installed globally and testcafe and the Electron provider installed globally and locally (i.e. run these configurations separately) but the same issue occurs.
Does anyone have any other ideas? Any help appreciated.
This is on Windows 10.
m
My project is built using Vue.js, powered by Nuxt
I’m using Cypress to write/run tests
I’m using CircleCI (v2) to run the tests
Locally, using Cypress’s instance of the Electron browser on macOS, the tests run correctly.
On CircleCI, the tests display a blank screen.
I’ve SSHed into CircleCI after the tests have failed, and if I make a curl request to the local server at that address, the correct HTML is returned to me.
My hypothesis is that the browser is not able to run Vue.js, but without a console log it’s hard to tell.
Any ideas as either how to continue debugging, or even better, fix it?
Edit: I’ve written an extra test to use another site, and it loaded correctly, so I can confirm that everything else is working.
Edit: It’s in my Nuxt config, just going through it now to pull out the line causing the problem.
So, of course this was super annoying. I’m not sure what the chances are of this happening to somebody else, but here’s the answer to my problem:
Google Analytics
On my CI I don’t have a GA code, and it was falling back to empty string, so it wasn’t able to load the page. It didn’t show up on the sever logs as it was an issue on the client side, and it’s not yet possible to easily get client logs using Cypress (coming soon).
Interesting, Thomas,
Could you open a GitHub issue with a link to a small repo that we can try ourselves? I do not see any factors that might affect running Cypress tests against Nuxt app on Circle
I recently installed CouchDB, but haven't gotten past the test suite yet. It seems that each time I run it, I get different errors than before, even without configuration changes.
The CouchDB Guide says the test suite shouldn't have "an inordinate number of failures", but what is "inordinate"? How many errors should I tolerate before I start developing?
For reference, here are the errors I'm seeing.
When installed from Ubuntu repository (Runs 1 & 2):
oauth
replication
rev_stemming
security_validation
view_conflicts
Then remedied by removing, then installing from source, as suggested here:
Run 3
attachments
jsonp
Runs 4 & 5
attachments
auth_cache
jsonp
list_views
rev_stemming
Run 6, after clearing cache, then restarting couchdb
No errors!
If each test passes individually, you are all set to proceed with development.
The test suite is not as reliable as we'd like due to its dependence on the javascript engine inside the browser and various timing and other issues. It is mostly used to help the developers validate a release.
We are planning to improve this situation in future releases, most likely by moving the test suite out of the browser entirely and running it from a known environment.
If you do want to see all tests pass, then be sure you are using FireFox (the only browser we officially support for running the test suite itself). You might also find it necessary to clear your browser cache too.