Azure pipeline - exclude 'already installed' packages in angular build from 'npm install' command

Question

0.00/5 (No votes)

See more:

Issue for - Azure Build pipeline for an angular project.
I have to run the npm install job every time the angular project builds with a new pull request.

Scenario - I have customized 2 packages for my project's requirement. I do not want to override these packages every time there is a npm install command. Once it is overridden manually it should not be touched.

Is there a way to ignore a particular package in package.json once it is installed?
in other words, Is it possible to install a npm package only if it has not been already installed?
Seeking for some direction from experts :)

What I have tried:

1. Exclude these packages from the package.json file

Problem with this solution - If I have to deploy my application on the new system, those packages will never be installed.

2. I added these packages into a different folder and tried to reference the packages from there. It is not working as expected.

Posted 10-Oct-23 7:35am

Schatak

Updated 10-Oct-23 7:55am

v4

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Wessel Beulink · Answer 1 · 2024-02-13T21:39:00

You can try the following;

Using npm-shrinkwrap.json
1. Customize and Install Packages: Initially install and customize your packages as needed.
2. Generate npm-shrinkwrap.json: Run npm shrinkwrap in your project directory. This command creates an npm-shrinkwrap.json file which locks down the versions of all installed packages and their dependencies.
3. Edit npm-shrinkwrap.json: In the npm-shrinkwrap.json, you can manually edit the entries for your customized packages to point to your specific versions or local copies. This way, whenever npm install runs, it respects the versions and sources specified in the npm-shrinkwrap.json, ignoring any updates or changes that would normally be fetched from the npm registry.

If that doesn't work, try with local paths:

Leveraging package-lock.json with Local Paths
1. Install Custom Packages Locally: Place your customized packages in a known directory within your project or somewhere accessible to your project.
2. Modify package.json: Reference these local packages in your package.json by specifying their paths instead of version numbers.

JSON

"dependencies": {
  "custom-package": "file:./path/to/custom-package",
}

3.Commit package-lock.json: After running npm install, ensure that your package-lock.json is updated and commit this file to your repository. The package-lock.json ensures that the exact structure of your node_modules directory is replicated on future installations, including the use of local packages.

I would advise to use the first to methodes, if that doesn't work you can go and override packages.

Using .npmrc for Overriding Package Locations
Configure .npmrc: You can use an .npmrc file to override the source location of specific packages. This is a bit more advanced and typically used to switch between different registries, but you can specify local paths or custom URLs for your packages.

However, this approach requires that your packages are structured and can be installed in a manner similar to those hosted on npm registries, which might involve additional setup for your custom packages.