What does yarn --prefer-offline do? - javascript

I assume when I install npm package say react for the first time with
yarn add react
this will save react file in local cache. I found .yarn-cache to contain many files. I assume it is yarn local cache folder so that when I install react again in the future, it will be installed from local cache, no??
If I need to install react again in the future, should I simply write this:
yarn add react
or this:
yarn add react --prefer-offline

My understanding is that by default, yarn will always try to download the package from the internet when you install/restore it, and will also store that in the cache, which means that in the future if you try to install/restore and don't have an internet connection, it can fall back on the cache and install from there if necessary. By specifying --prefer-offline, you are reversing this behaviour so that it will check the cache first, and only try to download the package from the internet if it cannot find it in the cache. This can make your install/restores significantly quicker, and will allow you perform repeatable builds, but you may not get the latest versions available (e.g. if you're using version specs like ~1.2.3). There is also an --offline option, which will throw an error if it can't find a package in your local cache (i.e. it won't ever try to download from the internet).
More info at https://yarnpkg.com/blog/2016/11/24/offline-mirror/

In order to use --prefer-offline you first have to setup your offline package repo.
Let's setup our cache in a hidden dir in the home folder:
yarn config set yarn-offline-mirror ./.npm-offline
Also set a config to have yarn clean the dowloaded tarballs:
yarn config set yarn-offline-mirror-pruning true
Now, whenever you run yarn install in some project, it will cache the modules in this directory, available for you to then fetch using yarn --prefer-offline.
When you want to later, perhaps in a new project, install from the cache you will need to specify the desired module version as it doesn't have a concept of latest. Easiest is to simply try to add:
yarn add moment
On my machine this prints:
error Couldn't find any versions for "moment" that matches "latest" in our cache.
Possible versions: "2.1.0, 2.13.0, 2.17.0, 2.17.1, 2.18.1, 2.19.1, 2.19.2, 2.19.3, 2.8.4"
// Note that above is not in semver order...
I can then install latest offline with:
yarn add moment#2.19.3
The Yarn blog post mentioned by #adrian elaborates on how to a per project cache and how to commit that for your team if desired. I myself use just one cache for in order to be ideally able to bootstrap new projects while offline.

A quite popular guy here at S.O. said:
"Read the Source, Luke!"
And here is the source of yarn CLI's --prefer-offline flag:
commander.option('--prefer-offline', 'use network only if dependencies are not available in local cache');
Enjoy!

Related

Local npm dependency with aliases

I want to use https://www.npmjs.com/package/boardgame.io but want to have it as local dependency to be able to debug, modify etc. So i cloned repo and in my app package.json i have
"boardgame.io": "file:~/Projects/Games/boardgame.io",
So far so good, but problem is that package makes use of exportAliases when i try for example
import { Client } from "boardgame.io/react";
i get Unable to resolve. It works just fine when i use npm published version of boardgame, so it leads me to suspicion
that there is some trick i dont know to make such packages working locally (boardgame.io is just example, with other packages problem is the same). Do you have any idea how to solve this?
I think you are looking for the npm link command.
Example:
cd ~/projects/package-to-link // go into the package directory
npm link // creates global link
cd ~/projects/your-project // go into some other package directory.
npm link package-to-link // link-install the package

How can I test local installation of an NPM package I've published?

I recently published a package to NPM. The package works well on my own computer, where I wrote the code, but upon npm install on a coworkers machine, I start receiving errors.
What is the best way to go about installing and testing my package on my own computer? I could trace through the errors on my coworkers computer, but I assume there is a way I can do this on my own machine.
You don't have to install it on your own computer first if you want to test it, you could write unit tests instead, since you have to require the package if you do (just like an npm install).
Check the package.json to see if all needed modules are listed under dependencies. (Delete the node_modules folder, run npm install and see what errors are given)
If there is a file called .npmrc, check what files/folders it lists to make sure it's not excluding important files from NPM.
Make sure your module has a module.exports object, to be able to access the objects/functions
If this all didn't help, it might be a more specific problem and a GitHub link would help us more

What is the step-by-step procedure for installing any npm module with Aurelia CLI?

I wanted to install jquery and found instructions here:
http://aurelia.io/hub.html#/doc/article/aurelia/framework/latest/contact-manager-tutorial/4
I then wanted to install "moment.js" and found instructions here ( I am not using typescript) :
How to import Moment-Timezone with Aurelia/Typescript
To install both of these with the Aurelia CLI the procedure is to install the respective npm module and then to manually modify aurelia.json in some way so the app recognizes it.
In the case of moments the instructions then say to place an import at the top of app.js , but this is not the case for JQuery.
First off , is there any way the changes to aurelia.json can be automated ( like a regular node.js package.json) so I don't need to manually do it and second, how do I know what modifications I am expected to make to aurelia.json ( or app.js or any other file) for the module I want to install?
With a basic node.js app its pretty simple , just npm install. With Aurelia its much more confusing.
Edit: There is also JSPM which I've read is used for front end libraries like the ones I mentioned above. However, the links with instructions for installation that I posted are not using JSPM.
Edit
I found some of the answers here:
http://aurelia.io/hub.html#/doc/article/aurelia/framework/latest/the-aurelia-cli/6
The CLI is still under development. I think the automatic adding of a package might some day be included in the CLI itself, for example with an install command.
The extra registration is required to register the package correctly for usage with RequireJS (http://requirejs.org/). And if the plugin exists of more than just 1 file, this registration is a bit more complex then just adding the name of the plugin.
There is an experimental CLI task here https://github.com/martonsagi/aurelia-cli-pacman that will do the automation for you.
Which can be installed by running:
npm install aurelia-cli-pacman -D
The above will install the package manager and register/ include itself in the tasks in your current project (be sure to run it with install, because npm won't run the post install script if you run it the i shorthand). Next, you can run the following command to install an extension:
npm i aurelia-interactjs -S
au pacman i aurelia-interactjs
The only downside for many might be that currently there aren't that many registry entries, but I think the author of the package would be very happy if you help him out by creating a pull to extend the registry. Would take you some time to figure out what would be the correct install/ import settings, but you will help out someone else and make them happy when they hit the same problem you experience :-).
JSPM has a same sort of issue around this, only is more matured/ the registry is bigger and/ or authors added specific information for JSPM installations to their package.json. For example: To install the above plugin with JSPM it will use the following highlighted section https://github.com/eriklieben/aurelia-interactjs/blob/master/package.json#L72,L86. The same is currently not possible with aurelia-cli, because the installation is done by NPM instead of through JSPM that redirects it to NPM.
If the author of the plugin didn't specify the JSPM section in the package.json, you would most likely and up with the same sort of issues. JSPM has a similar registry (https://github.com/jspm/registry/tree/master/package-overrides/npm) as aurelia-cli-pacman.

Compare local node module version with package.json version

I want to ask this question is because I met some problems when I co-work with other developers.
Sometimes, other developers update node modules version, and I pull the new commit and forgot to install new modules.
It would cause some problems when run the code. And I didn't realize the bug was caused by update module version at first. It took me some time to debug in wrong way.
Is there any method to solve this problem?
Like compare your local node_module with your package.json setting.
I think of one way is to create a git plugin. This plugin will notify you when package.json changed.
I also try to find some modules but what these modules do is to compare local version to npm registry version. (like npm-check-updates)
Is there anyway to compare local node_module with package.json setting?
I think it will also help when deploy the code to production mode.(to do the pre-publish check)
2 things:
If want to be notified when the package.json has been updated, I think the standard git pull command should be enough as it displays all the file updated by you co-workers commits.
If you want to avoid launching your dev environment with some missing dependencies, I think the best way is to add a grunt (gulp,or any other task runner) install-dependencies task that will be required for your grunt serve command.
Doing so, you'll never miss a package.json update, and this will force you to maintain all your local dependencies up-to-date and homogeneous with your team.
hope this help

Is bad practice to run "bower install" when deploying in production?

I am working on an application that uses bower.js; it's the first time I use bower, so please correct me if you see anything evidently wrong in my problem description.
------------------------------------------------
Coming from a Ruby background, I expect a package manager to have a .lock file, tracked under git, that tells me exactly which are the versions currently in use. This doesn't seem to happen with bower (am I right?).
A couple of days ago I deleted and re-cloned my repository, and ran bower install, thinking that such command would just install the required versions of the js components.
Then, today I did a one-line fix in a javascript file, compiled application.js using grunt watch, and realised that application.js was automatically filled up with tons of new code from bower component updates I wasn't aware of.
I found out that our bower components were under .gitignore, and that bower install, that I had run a few days ago, had actually updated two components without me noticing it.
When I realised what was happening, I immediately looked into our deployment procedure, which I paste here:
bundle install --path ${SNAP_CACHE_DIR}/.bundle
npm install -g bower grunt-cli
bower cache clean && bower install && bower list
bundle exec cap [our application name] deploy
Is this dangerous? Will bower install update all the components, that are likely not updated in my local version and are not tracked by git, ending up having completely different js code in production?
Is this dangerous? Will bower install update all the components, that are likely not updated in my local version and are not tracked by git, ending up having completely different js code in production?
Yes, this may happen and can cause problems. Although the impact will be limited as long as your dependency versions are specified as e.g. "~1.2.3", which will lock the major/minor version and only allow patch level updates.
In contrast to bower, the package manager normally used in node.js environments - npm - has a feature/command called npm shrinkwrap, which creates an npm-shrinkwrap.json file which locks down your dependency versions so that it is safe to run npm install afterwards.
This is probably what you would want.
However, bower as it stands does not have this feature yet - there is a discussion about it going on on Github e.g. here.
I think there currently are the following options to solve this problem in your situation:
Un-ignore and commit your bower_components (very ugly because of the huge amount of noise this produces in git).
Specify your dependency versions down to the patch level, e.g. "1.2.3" instead of "~1.2.3".
Culprit: If your dependencies have sub-dependencies, they might still be specified on the minor-version level, which means that even if your direct dependencies have a predictable version, your transitive dependencies may not.
Stop using bower and use npm instead (interface-/usability-wise, they are almost identical imho) and use npm shrinkwrap to lock down your dependencies.
Cheers, Alex

Categories