I've built a small vue project with 4 components and I want to build it to upload but it takes forever and building never completes.
I waited for 40 mins and building is not complete.
Here is a screenshot:
As was mentioned in comments building of application should finish in few seconds.
One of possible solution is to delete node_modules folder and install all deps again. It can help you.
Another possible solution it is to allocate more memory for task:
node --max_old_space_size=4096 node_modules/.bin/vue-cli-service build
This line will call node with increased size of memory (4GB) and will execute building task.
More about of how to serve and build application you can read here -
https://cli.vuejs.org/guide/cli-service.html#using-the-binary
Related
I have a Github Actions workflow that loops through a list of services and runs npm run test-compiled sequentially and takes 30 minutes to finish.
I am trying to see how I can improve the time taken to complete this step. One option I thought of was to create multiple jobs in the workflow and have each job run the test concurrently, however this always fails as files from the node install are missing.
Are there any recommendations on how to shorten the time needed for the workflow to complete?
I typed vue create "project name" and it is installing packages for some long time.
there is no error messages it just keeps on installing packages
When I vue create "proj name here" I says I need to change npm registry the one in China because my current is slow, It took me 2 hrs patiently waiting for nothing. This was not the same last year when I created new project. I found this tutorial helpful fixing slow creating a new vue https://ozorku.hashnode.dev/how-to-fix-vue-cli-slow-project-creation-cjzqkpx59001ivps1rw4wnhsa. In less than 5 mins or so I download it successfully.
I have encountered significant speed issues with vue-cli it definitely slows down your computer. Try closing everything except your terminal and see if that helps. The next step would be to free up memory by killing unneeded processes.
Step 1:
Check the vue configuration run vue config
Step 2:
Update the configuration file named '.vuerc' in the resolved path by running the command sudo nano and change useTaobaoRegistry to false
Step 3:
Save the configuration by pressing CTRL+X and then Y
I'm trying to build a vue.js app for production. This error message always appears midway through.
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
I already tried to increase the memory by adding --max_old_space_size=4096 and even tried to change it to 8192, but to no avail. I am using a Mac with 8 GB of RAM so I'm not sure why this is happening.
This is the code I run for npm run build:
vue-cli-service build --max_old_space_size=4096
I ran into this problem too. The memory limitation was with Node so running this command worked:
NODE_OPTIONS=--max_old_space_size=4096 npm run build
On Windows, use:
set NODE_OPTIONS=--max_old_space_size=4096
npm run build
The default memory limit for Node is 512MB, running this command temporarily increased it to 4GB.
If you have a large project with each .less file in every folder(such as components, views) you may have this problem.
I have solved it by move all .less file into just one folder "/assets/less/" and import all of them to "/assets/less/index.less"
I am having a build where in pre-compilation stage nuget restore is taking ~3 minutes to restore packages from cache and so does npm.
These two restoration from caches could run in parallel but I am not clear whether this is possible using the VSTS Phases.
Each phase may use different agents. You should not assume that the state from an earlier phase is available during subsequent phases.
What I would need is a way to pass the content of packages and node_modules directories from two different phases into a third one that invokes the compiler.
Is this possible with VSTS phases?
I wouldn't do this with phases. I'd consider not doing it at all. Restoring packages (regardless of type) is an I/O bound operation -- you're not likely to get much out of parallelizing it. In fact, it may be slower. The bulk of the time spent restoring packages is either waiting for a file to download, or copying files around on disk. Downloading twice as many files just takes twice as long. Copying two files at once takes double the time. That's roughly speaking, of course -- it may be a bit faster in some cases, but it's not likely to be significantly faster for the average case.
That said, you could write a script to spin off two separate jobs and wait for them to complete. Something like this, in PowerShell:
$dotnetRestoreJob = (Start-Job -ScriptBlock { dotnet restore } ).Id
$npmRestoreJob = (Start-Job -ScriptBlock { npm install } ).Id
do {
$jobStatus = Get-Job -Id #($dotnetRestoreJob, $npmRestoreJob)
$jobStatus
Start-Sleep -Seconds 1
}
while ($jobStatus | where { $_.State -eq 'Running' })
Of course, you'd probably want to capture the output from the jobs and check for whether there was a success exit code or a failure exit code, but that's the general idea.
A real problem here wasn't that VSTS hosted agent npm install and nuget restore could not have been run in parallel on a hosted agent. No.
A real problem was that hosted agent do not use nuget cache by design.
We have determined that this issue is not a bug. Hosted agent will
download nuget packages every time you queue a new build. You could
not speed this nuget restore step using a hosted agent.
https://developercommunity.visualstudio.com/content/problem/148357/nuget-restore-is-slow-on-hostedagent-2017.html
So a solution to take nuget restore time from 240s to 20s was to move it to a local agent. That way local cache do get used.
Observations:
On our Jenkins build server, we were seeing lots of msbuild.exe processes (~100) hanging around after job completion with around 20mb memory usage and 0% CPU activity.
Builds using different versions of stylecop were intermittently failing:
workspace\packages\StyleCop.MSBuild.4.7.41.0\tools\StyleCop.targets(109,7):
error MSB4131: The "ViolationCount" parameter is not supported by the "StyleCopTask" task.
Verify the parameter exists on the task, and it is a gettable public instance property.
Nuget.exe was intermittently exiting with the following access violation error (0x0000005):
.\workspace\.nuget\nuget install .\workspace\packages.config -o .\workspace\packages"
exited with code -1073741819.
MsBuild was launched in the following way via a Jenkins Matrix job, with 'BuildInParallel' enabled:
`msbuild /t:%Targets% /m
/p:Client=%Client%;LOCAL_BUILD=%LOCAL_BUILD%;BUILD_NUMBER=%BUILD_NUMBER%;
JOB_NAME=%JOB_NAME%;Env=%Env%;Configuration=%Configuration%;Platform=%Platform%;
Clean=%Clean%; %~dp0\_Jenkins\Build.proj`
After a lot of digging around and trying various things to no effect, I eventually ended up creating a new minimal solution which reproduced the issue with very little else going on. The issue turned out to be caused by msbuild's multi-core parallelisation - the 'm' parameter.
The 'm' parameter tells msbuild to spawn "nodes", these will remain alive after the build has ended, and are then re-used by new builds!
The StyleCop 'ViolationCount' error was caused by a given build re-using an old version of the stylecop.dll from another build's workspace, where ViolationCount was not supported. This was odd, because the CI workspace only contained the new version. It seems that once the StyleCop.dll was loaded into a given MsBuild node, it would remain loaded for the next build. I can only assume this is because StyleCop loads some sort of singleton into the nodes processs? This also explains the file-locking between builds.
The nuget access violation crash has now gone (with no other changes), so is evidently related to the above node re-use issue.
As the 'm' parameter defaults to the number of cores - we were seeing 24 msbuild instances created on our build server for a given job.
The following posts were helpful:
msbuild.exe staying open, locking files
http://www.hanselman.com/blog/FasterBuildsWithMSBuildUsingParallelBuildsAndMulticoreCPUs.aspx
http://stylecop.codeplex.com/discussions/394606
https://github.com/Glimpse/Glimpse/issues/115
http://msdn.microsoft.com/en-us/library/vstudio/ms164311.aspx
The fix:
Add the line set MSBUILDDISABLENODEREUSE=1 to the batch file which launches msbuild
Launch msbuild with /m:4 /nr:false
The 'nr' paremeter tells msbuild to not use "Node Reuse" - so msbuild instances are closed after the build is completed and no longer clash with each other - resulting in the above errors.
The 'm' parameter is set to 4 to stop too many nodes spawning per-job
I had the same issue. One old reference I found was in csproj files
<PropertyGroup>
<StyleCopMSBuildTargetsFile>..\packages\StyleCop.MSBuild.4.7.48.0\tools\StyleCop.targets</StyleCopMSBuildTargetsFile>
Also, I deleted the entire "Packages" folder that's located in the same folder as sln file after I closed the visual studio. It triggered VS to rebuild the folder and let go of the cache of the old version of stylecop
I've had the same issue for a while, builds were taking over 6 minutes to finish after some digging I found our it's node reuse fault so adding /m:4 /nr:false fixing my issue immediately