npm install时跳过指定模块？多源依赖场景解决方案问询

Great question! Let’s break this down clearly—first, the straight answer: npm doesn’t have a built-in way to skip specific dependencies during npm install, because its core purpose is to ensure your dependency tree is fully resolved. But there are several practical workarounds tailored to your scenario, where dev machines can’t access certain internal repos but CI/CD machines can. Here’s what I’d recommend:

1. Mark Internal Exclusive Dependencies as Optional #

Move the dependencies you can’t pull in dev environments from dependencies or devDependencies to the optionalDependencies field in your package.json. When you run npm install, npm will attempt to install these, but if it fails (due to proxy/permission issues), it’ll skip them silently instead of aborting the entire install.

How to do it: #

Update your package.json like this:

{
  "dependencies": {
    "lodash": "^4.17.21",
    "react": "^18.2.0"
  },
  "optionalDependencies": {
    "@internal/finance-sdk": "^1.0.0",
    "@internal/dev-utils": "^2.3.0"
  }
}

Critical Note: #

You’ll need to handle cases where these optional dependencies don’t exist in your code. For example:

let financeSdk;
try {
  // Try to load the real SDK
  financeSdk = require('@internal/finance-sdk');
} catch (error) {
  // Fall back to a mock in dev
  financeSdk = require('./mocks/finance-sdk-mock');
}

This way, your code runs smoothly in both dev and CI environments.

2. Use Environment-Specific Install Scripts #

Create custom npm scripts to handle dev vs CI installs, so you can explicitly remove or avoid installing inaccessible dependencies on dev machines.

Simple Script Example: #

Add these to your package.json:

{
  "scripts": {
    "install:dev": "npm install && npm uninstall @internal/finance-sdk @internal/dev-utils",
    "install:ci": "npm install"
  }
}

• Devs run npm run install:dev: this installs all dependencies, then removes the ones they can’t access.
• CI machines run npm run install:ci (or just plain npm install) to get everything.

Advanced Dynamic Filtering: #

If you want to avoid modifying the package.json directly, write a small Node script to filter out inaccessible dependencies before installing:

// install-dev.js
const fs = require('fs');
const { execSync } = require('child_process');

// Load the original package.json
const pkg = JSON.parse(fs.readFileSync('package.json', 'utf8'));

// Remove dependencies that devs can't access
const blockedDeps = ['@internal/finance-sdk', '@internal/dev-utils'];
blockedDeps.forEach(dep => delete pkg.dependencies[dep]);

// Write a temporary package.json
fs.writeFileSync('package.tmp.json', JSON.stringify(pkg));

// Install using the temp file
execSync('npm install --package-lock-only --package package.tmp.json', { stdio: 'inherit' });
execSync('npm install', { stdio: 'inherit' });

// Clean up the temp file
fs.unlinkSync('package.tmp.json');

Then add this script to your package.json:

{
  "scripts": {
    "install:dev": "node install-dev.js"
  }
}

3. Split Your Project with npm Workspaces #

If the code relying on internal dependencies is a separate feature or module, split your project into npm workspaces. This lets devs install only the core dependencies they need, while CI installs everything.

Setup Steps: #

1. In your root package.json, define workspaces:

   {
     "workspaces": [
       "packages/core",
       "packages/internal-services"
     ]
   }
   

2. packages/core holds your main app code and public dependencies (no internal repo stuff).
3. packages/internal-services holds code that uses the internal finance/dev dependencies.

Usage: #

• Devs run npm install --workspace packages/core to get only the core dependencies. They can mock the internal-services functionality during development.
• CI runs npm install to install all workspaces and dependencies.

4. Mock Internal Dependencies Locally #

Create mock versions of your internal dependencies and link them to your project, so your code thinks the real packages are installed—without needing to pull from the restricted repos.

How to do it: #

1. Create a mock package folder (e.g., mock-finance-sdk), initialize it with npm init -y, and set its name to @internal/finance-sdk in its package.json.
2. Write mock functions/classes that match the real SDK’s API.
3. In the mock folder, run npm link to register it with npm.
4. In your project root, run npm link @internal/finance-sdk to use the mock instead of the real package.

Devs can work with the mock, and CI will automatically use the real package when it runs npm install (since it doesn’t have the linked mock).

内容的提问来源于stack exchange，提问作者vitaly-t