In my nodejs project I had to modify 4 of the node modules and upload them to our private corporate registry so the project will download the modified versions during builds. I did this by changing the resolved field in package-lock.json for each dependency from our virtual npm registry which forwards downloads to the public npm registry to our private registry.
This is working for 3 out of the 4 modules, however 1 module, phantomjs-prebuilt, will not download the one I uploaded. When I view its package.json after installing, its _resolved field shows the correct private registry I entered in package-lock.json, but the module doesn't have my modifications.
If I create a test project with a package.json that has phantomjs-prebuilt as its only dependency and modify the lock file to download from the private registry it will download the correct modified version I uploaded. I'm assuming there must be some transitive dependency overriding it, but I thought I would be able to see that from the lock file and override it. phantomjs-prebuilt only appears once in my lock file and that's where I'm making the change to the resolved field.
I had a similar issue myself, recently. This may not help you in particular if releasing as a different version is not an option, but maybe others who stumble across this answer like I did.
What I did was to release a forked version of a package, under a new version.
So, I forked moddle-xml 10.0.0, and released a package 10.0.1337 into our private registry in Artifactory.
That way, I could replace the transitive package dependencies of a package that we used with the forked version 10.0.1337 (using npm-force-resolutions), not breaking any constraints like ^10.0.0.
EDIT: If you want to replace a particular outside version, I think you can work with exclusion / inclusion filters.
The Artifactory-based registry would then offer a single virtual registry containing both the npm-local packages (including my fork) and npm-remote packages (the normal stuff from the default registry) setup guide.
I would configure my local setup to only download from that virtual registry.
The Artifactory setup comes with a few pitfalls (like, you have to give read permissions to all physical repositories (npm-local AND npm-remote), not just the virtual one, and this one), but it works fine for me now.
(I'm sure something like this is possible with other than the Artifactory implementation, this particular thing is just the stuff I know)
Related
Trying to set up a proof-of-concept for the place I work using a private npm registry to limit the packages developers can download. I set up a feed on Azure Artifacts, and set the official npm registry (https://registry.npmjs.org) as the only upstream source. This feed was set as the registry in the npmrc file, and the project is correctly identifying that as the registry source. (per npm config get registry).
When a user (with permissions to install from upstream) tries to install a package from the empty feed, it installs the package (from the upstream) correctly along with all of its dependencies. It also saves the package to the Artifacts feed, but only some of its dependencies are saved to the feed. There seems to be no rhyme or reason as to which dependencies it saves, as it changes almost every time I install the same exact package.
When a user that does not have permission to install from an upstream source tries to install that same package, it fails on one of the dependencies that wasn't saved, giving a 404 error for the artifacts feed, saying that the package was not found in the registry.
I've set up quite a few different feeds, both project-scoped and organization-scoped to see if I perhaps fiddled with the wrong settings/set something up wrong, but I get the same behavior with every feed I set up.
Are there certain criteria that determine whether or not a dependency is downloaded, and is there a way that I can make it so all dependencies are saved to the feed when a package is installed from the upstream?
Are there certain criteria that determine whether or not a dependency is downloaded
npm has a local cache. You'll want to run npm cache clean before testing. Otherwise, there's no guarantee that the package will be downloaded. It may be installed from the cache instead.
and is there a way that I can make it so all dependencies are saved to the feed when a package is installed from the upstream?
I suppose you can try disabling the cache, but that will likely greatly inflate installation times for your users. You may only want to do that while testing. That said, there are various somewhat-hacky ways to do it more permanently-ish. You can use the force config option but that has other side effects. I imagine you can set the cache to be /dev/null or something like that, although I've never tried that. There are other ideas in the answers provided to the "Disable npm cache" Stackoverflow question.
I am using a sigmajs library for creating node based graph visualisations. But the library package had a few bugs, so I modified a few files in the source code of the library and fixed them.
I have hosted my graphs on django server, and whenever I host it, the sigma package in the package.json gets loaded dynamically each time. The static library files on my machine which I had modified and fixed bugs don't get loaded. So,I get the same old package and not the modified one.
How do I access the modified library package dynamically when I host the server.
My advice is that of copying your fixed version of the library on server and install it from local path instead of remote npm repository like this:
npm install --save /path/to/fixed/lib/dir/in/server.
See this answer: npm local install
Pay attention that your fixed lib won't be sync with official one.
I don't know how you modify the library but i suggest to fork the official repository and syncronize your local one with remote one as for example explaind here sync forked repo github.
In this way you can sync to official repo while you mantain your fix and you will install your modified local one. Eventually consider to open issues and PR on sigmajs official repo to apply your fix directly to official library. If they will be accepted you can then install directly official version.
I'm planning to setup private npm registry for our internal Node.js/web projects, and seems that Verdaccio is the best open-source choice for it.
Before starting to publish my private packages there I want to be sure that an easy way to move Verdaccio installation with all published packages to another server exists. Here is a similar question for Sinopia Verdaccio project is forked from. Folks there say that we should simply move entire sinopia directory to another server. But what is the exact directory and what is the directory (or, probably, few directories) for Verdaccio?
I have Node.js installed by nvm script and Verdaccio installed globally the following way:
npm install -g verdaccio
Here Verdaccio core maintainer. Not long time ago I've written down the required steps to move from latest Sinopia to any Verdaccio (v3,v4-alpha).
In a nutshell (for UNIX):
The folder ~/.local/share/sinopia must be renamed to ~/.local/share/verdaccio
The folder ~/.config/sinopia must be renamed to ~/.config/verdaccio
There is an additional step, not required, but recommended:
The file ~/.config/sinopia/storage/.sinopia-db.json must be renamed to ~/.local/share/verdaccio/storage/.verdaccio-db.json
To find the Windows location, check the following link.
I hope this helps. Original source in the link below.
https://verdaccio.org/blog/2019/02/24/migrating-verdaccio#migrating-from-sinopia-140-to-verdaccio-2x-3x
I'm trying to implement a developer workflow with docker, with the ability to develop offline (as in, not having to run npm install when you switch between branches that have differing dependencies)
The most intuitive way to do that is to store dependencies in source control. This has its own issues especially when using modules that compile dependencies. I have tried nearly everything I could think of and find:
npm packing my projects dependencies, storing in source but this doesn't store my dependencies' dependencies
storing node_modules in source, copying this to the container and running npm rebuild but it doesn't actually trigger a rebuild
running npm install --no-registry so t triggers a rebuild but doesn't try to call out, but it actually calls out to the public registry anyway
other solutions I've seen like Node-PAC seem abandoned
npmbox looks the most promising but it requires that it's installed on the target globally, which would work in a container I can build but not production, unless we start deploying containers in production.
Is this a fruitless effort? Lack of network access is rare and would only really be needed when installing a new module or moving between revisions that have differing dependencies
Another option is to setup a private npm repository and to configure it to cache public repository. There are several options to implement this, I would recommend to try Nexus: https://www.sonatype.com/nexus-repository-oss
Is it possible to force an external npm dependency to use a different node.js package that offers the same API but a different implementation?
If you're willing to do that and that module is open source you could fork that on github, change their package.json to include the module you want and use github url for your own package.json like this:
"modulename": "git+https://git#github.com/user/repo.git"
You should be able to download the source of whatever module you would prefer and put that folder within your node_modules folder. From that point you simply require it within your Node.js app like any other NPM module.
I recommend downloading the code for the API you want, creating an src/assets folder, placing it in there, changing the package name in package.json to something not used in npm, then using 'require('newPackageName')' within your code.
If you decide to use some of package.json's capabilities to point towards a specific version (like using "1.4.7" as opposed to "^1.4.7") or if you point to a github address, be careful when you run npm update. It will replace your URL with the latest version in npmjs.org with that specific name. I don't know if it still does this in newer versions of npm, but in the version that works with Node.js 0.12, this is the default behavior.
I can tell you that node shrinkwrap will work, but it will prevent any other packages from being updated as well. No, you cannot just have one shrinkwrapped dependency, it has to be all of them, or npm update won't work.