Npm force download new version of package - npm

I'm working on 2 projects, one library project is the npm depencency of the others.
The library project is automatically published to local npm registry (nexus) by CI (Gitlab), so developers that are only working on 2nd project don't need to download library project (at least this is the welcomed solution).
However, after deleting node_modules/mylibrary and calling npm install, I've found out, that I've got... old version of the package. The library was correcly built and our nexus allows redeploy, and it works perfectly in Gitlab CI (the project gets always the actual version of library package) so it looks like something was cached locally somewhere else (not in project itself).
How to force npm to download the actual version of the package, purging local cache if necessary? Increasing the library version after each commit is not a viable solution (if it was, there would be never the concept of snapshots in maven).

Related

Managing feature branch versions with npm for component packages

We have a React App which uses some components written by us and published to our internal npm repository. Our code is maintained in Bitbucket Data Center, the build is done with Bamboo and the npm repository is hosted in JFrog Artifactory. We work with feature branches and pull requests for developing new features.
It happens often that a new feature in the app, requires a change in the component. In this case, each repository (the App and the component) will have its own feature branch and pull request. Many times the component interface changes, so that the App needs the pull request version of the component and not the mainline one to build and to be tested.
The build is done exclusively by the build server, so that the bundled javascript files are not committed to git.
Let's say the component has version 1.0.0. A new feature in the App needs a change in the component. In this case, the component version will incremented to 1.0.1. We don't want to publish it to Artifactory, until version 1.0.1 is tested, but at the same time, the build of the new App version needs the changes from version 1.0.1.
Our current solution is to change the package version of the component during the build of feature branches to something like 0.<Ticket #>.<Build #>. This 0.x.x version will be published to Artifactory so that the App feature branch can use it to compile.
We use 0.x.x so that the version is never bigger than the current released version. Once the component is merged to the main branch, it will compile with the right version (1.0.1) and will be published to Artifactory again.
I find this solution cumbersome, it requires some funny build scripts, making sure that the branch name always follows some convention and teaching developers about it.
I wonder if there is a better way for managing pull requests and feature branches using npm, without having to manipulate the package.json during build time, depending if it is a feature branch or the main branch.
Sounds like you are using artifactory like a secondary version / staging for the npm package, just use npm?
I am not in devops, but have worked on a few packages, testing a package that has not been released does not sound like testing the package - what about using a beta tag npm publish --tag beta, pulling that into your app npm i package#beta then testing your application in a staging environment?
As i expect you know if you apply a tag then the tag would need to be specified to be pulled into a repo so you can use it to deter users from using that version of the package - an i believe you can delete versions later if you are dead set on not having it public.
Here is a medium article which may be helpful?

How does the NPM cache and node_modules folder work hand in hand?

I am trying to demystify this NPM behavior. I have a custom library which I create for an Angular Project. The library is copied directly to the Node modules directory in my Angular Folder to test any new functionalities that I add on whatever project is using it. However, I notice the older version of the library is being used by the project.
I wonder whether this is due to the NPM Cache.
So my question is, how does the NPM cache and Node_Modules folder work hand in hand?
I can't directly answer as to how the cache relates to node_modules, but I can say that your package-lock.json file is likely the culprit behind your outdated packages. Try running npm update. If that doesn't work, try deleting your package-lock.json file and running npm install.
If that also doesn't work, make sure you have the correct version specified for your library in your project's package.json file. latest will grab the latest release available, ^1.0.0 will grab the latest minor and patch releases, ~1.0.0 will grab only the latest patch releases, and 1.0.0 will only grab that exact version.

Do I really need to put anything in "dependencies"?

I'm developing a browser-side package, with several runtime dependencies and developing tools. As suggested, I install them using NPM as dependencies and devDependencies respectively.
Eventually, before I publish it, I always compile every source file and external dependencies into one minimized file.
When I try to install it in another project, however, I noticed that all "dependencies" packages are also installed. I assume it's a standard NPM behavior, yet these packages should not be needed, as I've already compressed them all into my own .min.js file.
Should I just move them all to "devDependencies"?

TFS npm install Build Task Hanging?

We are using TFS Build Tasks and one of the tasks runs npm install. This is NOT through a batch or powershell file.
It runs successfully but it looks like it completes and then hangs for about 3 to 4 minutes. I know this because the task summary says it successfully completed but it doesn't start the next task for 3 to 4 minutes.
Originally when I added the task, I don't think it would hang like this. I'm not sure what changed.
I tried using npm set progress=false, recommended from this forum and explained in this article. I haven't added npm-cache because it doesn't seem to be relevant; remember, the build task completes successfully and then hangs.
What could cause the npm task to hang after completing?
According to your description, it is make sense. NPM install is just wasting time because it takes 3-4 minutes to determine the packages are already installed.
Fist try to run you npm from the console to see the performance on TFS is normal or not. If all of your NPM tasks are taking long time, one possibility is related to nodejs version.
For instance, you are using a latest version such as nodejs (8.2.0) installed on the build agent. Then downgrade to the latest LTS (long term support) version (6.11.1) may resolve the issue for you. Details please have a look at this blog.
Another way is using npm-cache as an alternative way since you use on-premise build agents for build.
It is useful for build processes that run [npm|bower|composer|jspm]
install every time as part of their build process. Since dependencies
don't change often, this often means slower build times. npm-cache
helps alleviate this problem by caching previously installed
dependencies on the build machine. npm-cache can be a drop-in
replacement for any build script that runs [npm|bower|composer|jspm]
install.
How it Works
When you run npm-cache install [npm|bower|jspm|composer], it first
looks for package.json, bower.json, or composer.json in the current
working directory depending on which dependency manager is requested.
It then calculates the MD5 hash of the configuration file and looks
for a filed named .tar.gz in the cache directory ($HOME/.package_cache
by default). If the file does not exist, npm-cache uses the system's
installed dependency manager to install the dependencies. Once the
dependencies are installed, npm-cache tars the newly downloaded
dependencies and stores them in the cache directory. The next time
npm-cache runs and sees the same config file, it will find the tarball
in the cache directory and untar the dependencies in the current
working directory.
A sample for your reference: Speed up your npm dependent CI build

npm/bower - Basic questions(Why it requires for just AngularJS then?)

I read about npm and bower, differences, usage, how it works, purpose as well. All explanation says that to work in NodeJs. But when I searched for AngularJS2, the tutorial says use npm. I have some basic questions based upon the understanding that npm basically for dependency management or packages to be installed.
How my Java/Eclipse workspace knows that npm installed the particular JS library/file, what path should be given in the html/web page for including those files/libraries?
If I move the web application to production, how will the server gets those dependent libraries? Even if server gets it, it might be installed in different folder. Basically how it can be managed with a web applications in different environments for just AngularJS app?
Can anyone please help me to have better understanding?
Finally found the answer. NPM is node package manager which helps basically to download the dependencies (almost like maven, gradle in java).
npm software needs to be installed in developer's machine.
Add the required dependencies in the package.json in the root folder of AngularJS application.
Open the DOS command line and navigate to project root folder(workspace/project in eclipse), then type npm install which will download all the dependencies mentioned in the package.json to a folder called npm_modules inside project folder.
The other and important advantage is npm can be used to install browser agent as well. So npm start command will open the browser and will load the application automatically in browser. Developer does not need to be aware about NodeJs. One more benefit of using this approach is the browser will get refreshed automatically when any update in the JS file gets saved.