Local (offline) npm repository

Prehistory

Having decided to sell at a high price, I found myself at an employer, where there is no Internet not only in the industrial circuit, but also in the maiden (the situation is in fact not uncommon in many, so to speak, "enterprise"). There is IE in the console, where you, my dear reader, can of course look at Habr or stackoverflow, but no more. In general, I repeat, the situation is not exceptional, you can live with it - here it is, my personal laptop, on which I write it, is on the table ... whether wifi, lifted by many employees, is cellular as a modem, in general, if it is not defense / any services of three letters (here I advise you to go in official-expensive ways, what a couple of words will be about below) and there is no radio monitoring service, then you are free with your personal laptop to do anything (within the limits of acceptable :)), well at least that is how it looks with us. The ability to drag files into the dev environment is somehow, but I really didn’t like the decision to keep the node_modules in the codebase and I rolled up my sleeves (I rolled up the sleeves many times about moving from TFS to git and about the local nuget repo, but these are separate stories, also not devoid of drama, but about them sometime next time). There are several fairly expensive solutions to the issue, it is quite possible that I could even push through some Artifactory, but when I imagined how much strength it would take and most importantly how long it would be solved, coordinated and implemented, it was decided to go cheap and cheerful.

Disclaimer: since I had a windows-environment, I describe in detail exactly the work in the Windows console, but in fact there will be differences only at the end, when you want to raise the final result as a service / daemon.

Do not hurt me, devotee, how?

In action are involved:

• Computer with Internet access - call it source
• A computer without access in the corporate network - we call it the target machine

On the source and on the target machine should be node.js (the easiest way is if it is the same or close versions).

Create a daddy on the source code, wherever we call it, for example, verdaccio:

mkdir verdaccio cd verdaccio 

After locally installing Verdaccio, this is a very useful thing, based on the old project of sinopia. Read more here: https://verdaccio.org/ .

If it is short, then it is a proxy for npm which is able to cache. For so many users of this package, the key possibility is the ability to publish privately, but my case is somewhat different, I wanted to cache everything I needed for work and a little more, and then transfer it all to the target machine. Looking ahead, I will say that everything went pretty painless, except for the transfer of node-sass. I spent her day and a half on her tarball (the native part is there, which is loaded from the github during the installation process or is going to gyp, if it doesn’t work out of it, think about it, it’s going to be on every local development machine), but also another story.

Everything is simple:

 npm i verdaccio 

In general, the manual recommends putting it globally, but in fact it is not at all necessary, moreover, we want to localize all this disgrace in one folder, so that it can be copied later. Because so ...

Run the package, it will create the repository and the default configuration:

 .\node_modules\.bin\verdaccio.cmd 

It was here that they told us everything, where the config is, on which port we hang.

In principle, you can already go to the specified address and see something like this:

Now we need to do a few things:

• Clear npm-cache ( more details here , if briefly kill the contents of % AppData% / npm-cache )

  
  

• Run

  
  

   npm set registry http://localhost:4873/ 

  
  

• Copy config.yaml to our cozy verdaccio folder

  
  

• Make sure that the uplinks section of this file looks like this:

  
  

   uplinks: npmjs: url: https://registry.npmjs.org/ cache: true 

  
  

• At the end of the config add:

  
  

   listen: - 0.0.0.0:4873 

  
  

  If you do not do this, then you will not be able to reach the local address on the target machine later.

  
  

• Actually we are ready, now all the packages that we take through npm install will settle into ./storage, which is what we need. Restoring the target project, set additionally:

  
  

 npm i node-windows 

Everything, then take the folder and send it to the target machine in any way you can (they need admin rights, yes). You can already there, you can immediately create a file in the root of the same installservice.js folder:

 var Service = require('node-windows').Service; var svc = new Service({ name: 'VerdaccioSvc', description: 'Verdaccio - npm local repository', script: ' <   >\\node_modules\\verdaccio\\bin\\verdaccio', nodeOptions: [] }); svc.on('install', function() {svc.start();}); svc.install(); 

Run:

 node installservice.js 

Enjoy!

In general, a rather small amount of blood managed to get a local repository, builds are being built, developers are developing everything in this world in their places. And yes, subsequent synchronization comes down to copying the contents of ./storage .

This was all recorded partly as a reminder, partly in order to save you the habrauser time (the task is hardly solved too often), because if the stone flower does not come out - write boldly, there is a chance that I forgot to describe some detail, and if not forgotten, suddenly, what will help ...