When I add a new package to an existing installation where yarn install has already been run, it takes 5 minutes to add a new dependency, which is as slow as if I just did yarn install without node_modules there yet.
Is this normal?
I'm using Yarn 0.17.9 on Windows 10 x64. I did make Windows Defender ignore my project directory and yarn global cache directories.
EDIT: here are some benchmark results I did. Based on them, it seems that yarn add is actually 30-40% faster, and the real issue is rather just that yarn is 500% slower on Windows
EDIT 2: I have confirmed that indexing hasn't been enabled for the project and yarn cache directories. But now I have upgraded yarn from 0.16.1 to 0.17.9 and there was a 35-50% increase in speed in Windows! But it's still 350-400% slower than in Linux. I have updated the benchmarks.
There seems to be Github issue for the Windows performance issues: https://github.com/yarnpkg/yarn/issues/990
The benchmark:
--
Windows - yarn install (cached):
Done in 172.29s.
Ubuntu - yarn install (cache):
yarn install 48,75s user 11,32s system 117% cpu 51,161 total
--
Windows - yarn add lodash:
Done in 143.11s.
Ubuntu - yarn add lodash:
yarn add lodash 33,42s user 5,72s system 108% cpu 36,203 total
--
FYI the Ubuntu benchmarks were run on the same folder on the NTFS drive.
Project that was used for the benchmarks: https://github.com/amcsi/szeremi
Disabling windows search indexing on your work folder and yarn cache folder as well as disabling windows defender completely or on a folder should give you significant performance boost. I've got 30-50% decrease on similar system with SSD drive, originally timings were as yours.
Disabling it on Yarn cache folder would also give you some speedup. Its location is shown by yarn cache dir command, %USERPROFILE%\Local Settings\Yarn\cache by default.
To disable search indexing on a folder, find it in Explorer, right click, then Properties - General - Advanced, uncheck the "Allow files in this folder to have contents indexed in addition to file properties" checkbox, then Apply the changes.
This performance issue already exists on yarn github (Oct'2016) and is still open to the moment: https://github.com/yarnpkg/yarn/issues/990
My experience...
Doing a yarn start is excruciatingly slow.
My setup.
I am running WSL2 Ubuntu 20 on windows 10 home.
I have my WSL src directory a sym link to windows c:\Users\chai (as opposed to whatever filesystem WSL has me in ie. the native WSL filesystem).
ie.
Filesystem Size Used Avail Use% Mounted on
C:\ 476G 395G 82G 83% /mnt/c
I am running the yarn which is installed via WSL2 Ubuntu (ie. so it is the linux version, not the windows version of yarn).
V v slow.
I experimented and copied the same src files into a non-symlinked directory.
ie. under ~/tmp which is a WSL filesystem and not under the windows filesystem.
Filesystem Size Used Avail Use% Mounted on
/dev/sdb 251G 11G 228G 5% /
And the speed now is as per expected... ie. normal (or relative to previous behaviour, blindingly fast).
So I am now using the latter setup for my react projects.
For me worked downgrading from WSL2 to WSL1.
On WSL2 yarn install of my boilerplate took 890sec
on WSL1 - 245sec.
On standalone Ubuntu - 130sec.
https://github.com/microsoft/WSL/issues/4197
I used to have the same issue. It used to take 30+ Minutes to just install one package. I had my projects on an external drive and network drive and I tried adding scan virus exception path, opening firewall etc. None enhanced the speed. However, as soon as I git clone to, let say C:/New Folder/my repo. It took 1.5 seconds. I hope this resolves the issue for some developers.
Related
It is an expo-eject project and the commands I have used after cloning the project are:
Yarn,
Yarn start,
Yarn android,
And it does not show any error but gets stuck on a same point everytime when I try to run the project.
The project runs fine on the laptops of other teammates, but I am facing this issue.
Here are the versions of the installed tools:
Nodejs 14.17.6,
Expo 4.11.0,
React-native-cli 2.0.1,
I am adding an image that shows where the project gets blocked.
This is the issue in running project.
Had the same issue, and tried #usama-alaf reply, which consisted of:
Installing the right SDK for the Android device
Linking the SDK path under project/android/local.properties
But none of the above worked for me. Digging a little deeper, I found this Github issue from Willem Horsten, where the developer states that there was a yarn.lock file on one of his Hard Drives. I'm actually running my development environment on a secondary HD, and I also had a lock file in the root of the drive, but after deleting it, nothing changed.
Here's what actually worked for me. I was running Node v12, and trying to build the project, and trying to check whether the Node version was the culprit, I did this:
Deleted my node_modules, yarn.lock, and all other lock files I could find (for some reason there was also a package-lock.json file on the project)
Since I'm using NVM, I switched to Node v15.14.0 (the latest I have installed).
Installed the dependencies again with yarn install
Ran yarn android, and the build worked this time.
TLDR;
Is it possible, in a Windows environment, to set NODE_EXTRA_CA_CERTS in a way that works with NPM packages' post-install scripts, without making system changes, configuration file changes, or changes that require admin-level permissions?
Details
This has been driving me nuts.
I added image optimization to our Webpack build process via imagemin, imagemin-webpack, and the various imagemin format-specific plugins.
All of the imagemin plugins have one thing in common -- during post-install, they:
a. Attempt to download a pre-built EXE.
b. If (a) fails, they attempt to build the EXE from source.
I.T. snoops on our traffic, so (a) fails due to the "self-signed certificate in chain" error when attempting to fetch the remote EXE. (b) fails because our studio is Windows-based, and we don't have all the various build tools installed to make that happen. It's also not reasonable to have them installed on every machine where npm install might be run.
I did some digging (thanks S.O.), found our company's CA certificate, added it to the repo, and was able to get (a) working with the following commands:
> SET NODE_EXTRA_CA_CERTS=%cd%\ca.cert
> npm install
I thought I was home free at that point -- all I'd have to do is add this npm script to our package.json:
{
"preinstall": "SET NODE_EXTRA_CA_CERTS=%cd%\\ca.cert"
}
But that doesn't work. I'm guessing it's because there's a separate process involved, and the environment variable doesn't carry over to the other process.
Note that this does work, but is absolutely awful:
{
"preinstall": "SET NODE_EXTRA_CA_CERTS=%cd%\\ca.cert&& npm install imagemin-gifsicle imagemin-mozjpeg imagemin-optipng imagemin-svgo"
}
Is there a way to set this environment variable automatically in a way that works with NPM packages' post-install scripts?
I'd like this to be transparent to other team members so that they can just continue to npm install without any additional steps, system changes, or configuration file changes if at all possible. Some team members are not developers, so while they're used to running npm install, I don't want to introduce any additional complications. I super appreciate any help in advance!
Have you tried
npm config set cafile "<path to your certificate file>"
I am using VueJS and Yarn.
Problem is:
I was running yarn build AND npm run build but both create a dist folder with an old version of my code!
First time I face this problem.
What I have tried and checked:
I have tried to clear browser caching.
Tried to open from totally different device.
Run yarn cache clean and npm cache clean
But nothing worked! I always get an old version of code which I don't even know how!
Also I get this message while building saying:
asset size limit: The following asset(s) exceed the recommended size limit (244 KiB).
EDIT:
I have fixed the asset size limit but still got the same problem!
yarn build compile a different old version than that yarn serve!
I have an application building in Nw.js. Its almost done, but now facing an issue. While on clicking nw.exe on code (development) it is opening very fast, within in 2 seconds. But when I create a build using nwbuild -p win64 . , it is taking a lot time of time, say a minute to open and giving a feeling that app is opening itself.
The code base when built, the .exe is 21 MB size. Appreciate, if some one could help me to understand why this happens and what to make it open faster.
nwbuild is not recommended by official now, maybe try nwjs-builder-phoenix or create you own distribute script. As I remember, nwjs-builder-phoenix also not handle node_modules folder size very good.
Here is how I distribute my package:
copy NW.js binaries client to dist folder
copy my working source project into a folder named package.nw(Windows) or app.nw in nwjs.app/Contents/Resources/(MacOS)
run npm prune --production under the path you just copy your source into. https://docs.npmjs.com/cli/prune.html
using npm package plist(for MacOS) or rcedit(for Windows) to change the binaries client's information about version, nanme, author ..etc
For mac these is alot of things needs to be changed if you want to publish to appstore http://docs.nwjs.io/en/latest/For%20Users/Advanced/Support%20for%20Mac%20App%20Store/
Does anyone know how to install GameClosure on Windows? According to the docs, on the installation guide, only osx is supported, although they have some success running on Linux and Windows. Unfortunately they don't expand on how to do this and a Google turns up only one promising looking page which returns a 404 (there is a cached version but it only seems to be a half article).
I have successfully installed the GC DevKit on Windows, there are a few additional steps like creating symbolic links BEFORE trying to install the GC DevKit.
Follow these steps carefully and you shouldn't have a problem getting it up and running. Read through them and try to understand what is required first.
Download the list of required items (Windows builds for Git, Node and Java) from the install guide.
Open up Git Bash (find it on the start menu under Git)
Continue with the install guide by cloning the repo (git clone https://github.com/gameclosure/devkit).
The files would have been installed to %USERPROFILE% if you did not change the directory while in Git Bash.
Move all the files in devkit\SDK somewhere else but make sure they are gone from that directory.
Open a normal command-prompt (cmd.exe).
Create symbolic links for everything that WAS under the devkit\SDK directory using mklink (available in Vista and above) from the command-prompt (not the Git Bash console). The files you moved in step 5 will contain the path as text that the link should be pointed to EG: > mklink /D "%USERPROFILE%\devkit\sdk\squill" "..\lib\squill\"
JSIO is special and actually needs to exist in a sub-directory at the time of writing. Create the directory devkit\SDK\jsio and then create a symbolic link INSIDE that going back one more relative path. EG: > mklink /D "%USERPROFILE%\devkit\sdk\jsio\jsio" "..\..\lib\js.io\packages\"
Go back you your Git Bash console and now continue with the installation for GC DevKit by switching to the devkit directory running the ./install.sh script as described.
Run basil by executing node src/basil [command]
If all the correct pre-requisites were in place everything should go smoothly. If basil throws errors it's more than likely the symbolic links, just check that everything is pointing to the right place and run ./install.sh to try again.
Good luck!!
There is now a full guide to installing Game Closure SDK on Windows here (I have also posted the contents in pastebin here in case the previous link disappears)
It's quite a process to get everything installed and configured, and looks like you can only develop for Android using the windows version of the SDK, but I may be mistaken
I wasn't able to get it installed on windows, but it's easy enough to install on linux, so I ended up using virtualbox and a linux vm. Cygwin could be another option but I didn't try it so unfortunately can't say for definite whether or not it would work