运行npm脚本时覆盖package.json键值，Electron多环境构建配置问题

Hey there! I’ve worked through exactly this scenario with Electron Builder, so let’s walk through how to set up dynamic configuration overrides and ensure your different app variants can live side-by-side on the same device.

Step 1: Set Up Environment-Driven Build Scripts #

First, we’ll use environment variables to define unique parameters for each app type. Install cross-env (to handle environment variables consistently across Windows/macOS/Linux) if you haven’t already:

npm install cross-env --save-dev

Update your package.json scripts to include build commands for each app type. Each command will pass unique values for your app’s identity and configuration:

"scripts": {
  "build:type-a": "cross-env APP_TYPE=type-a SERVER_URL=https://server-a.example.com PRODUCT_NAME=MyApp-A PACKAGE_NAME=com.mycompany.appa electron-builder",
  "build:type-b": "cross-env APP_TYPE=type-b SERVER_URL=https://server-b.example.com PRODUCT_NAME=MyApp-B PACKAGE_NAME=com.mycompany.appb electron-builder"
}

Step 2: Create a Dynamic Electron Builder Config #

Switch from a static package.json builder config to a electron-builder.config.js file. This lets you dynamically read environment variables and adjust settings on the fly:

const path = require('path');
const fs = require('fs');

// Pull in variables from our build scripts
const { APP_TYPE, SERVER_URL, PRODUCT_NAME, PACKAGE_NAME } = process.env;

module.exports = {
  // Critical settings to avoid installation conflicts
  productName: PRODUCT_NAME,
  appId: PACKAGE_NAME, // OSes use this unique ID to separate apps—never reuse it!
  directories: {
    output: `dist/${APP_TYPE}` // Output each variant to its own folder to avoid overwrites
  },

  // Update your app's internal config before packing
  beforePack: async (context) => {
    // Path to your app's config file (adjust to match your project structure)
    const appConfigPath = path.join(context.appDir, 'src', 'app-config.js');
    
    // Read and rewrite the config with environment-specific values
    let configContent = fs.readFileSync(appConfigPath, 'utf8');
    configContent = configContent.replace(
      /serverUrl: ".+"/,
      `serverUrl: "${SERVER_URL}"`
    );
    configContent = configContent.replace(
      /type_of_application: ".+"/,
      `type_of_application: "${APP_TYPE}"`
    );
    
    fs.writeFileSync(appConfigPath, configContent);
  },

  // Add your existing Electron Builder platform settings here
  win: {
    target: 'nsis',
    // ... other Windows-specific config
  },
  mac: {
    target: 'dmg',
    // ... other macOS-specific config
  }
};

Step 3: Separate App Config (Optional but Recommended) #

Avoid modifying package.json directly (which can mess with version control) by moving app-specific config to a dedicated file like src/app-config.js:

// src/app-config.js
export const appConfig = {
  serverUrl: "https://default-server.example.com",
  type_of_application: "default"
};

This is the file we rewrite in the beforePack script, ensuring each build gets the correct values.

Step 4: Inject Variables Directly (Alternative for Webpack Users) #

If you use Webpack to bundle your Electron app, you can skip the config rewrite step by injecting environment variables directly into your code. Add this to your Webpack config:

const webpack = require('webpack');

module.exports = {
  // ... your existing Webpack settings
  plugins: [
    new webpack.DefinePlugin({
      'process.env.SERVER_URL': JSON.stringify(process.env.SERVER_URL),
      'process.env.APP_TYPE': JSON.stringify(process.env.APP_TYPE)
    })
  ]
};

Then use the variables directly in your app code:

console.log('Connected to:', process.env.SERVER_URL);
console.log('App Variant:', process.env.APP_TYPE);

Key Checks for Coexistence #

• Unique appId: This is non-negotiable—OSes use it to distinguish apps. Never reuse the same ID across variants.
• Distinct productName: Ensures your apps show up with unique labels in start menus, docks, and file explorers.
• Isolated output directories: Prevents build artifacts from being overwritten between different app type builds.

Test each build command to verify:

1. The app installs without conflicting with other variants
2. The correct serverUrl and type_of_application are active in the running app
3. The app’s name and bundle ID match your intended values

内容的提问来源于stack exchange，提问作者Harshveer Singh