Absolutely, the deprecation and CSP compliance issues with script-loader are super frustrating—let’s walk through some solid alternatives that keep your code secure, maintainable, and aligned with modern web standards.

1. Use imports-loader (Webpack Official) #

This is the most reliable official replacement—it’s actively maintained, doesn’t rely on eval, and lets you explicitly run scripts in the window context to attach variables to the global namespace.

Setup Steps: #

• First install the loader:

  npm install imports-loader --save-dev
  

• Add this rule to your Webpack configuration (example for making jQuery’s $ globally available):

  module.exports = {
    module: {
      rules: [
        {
          test: require.resolve('jquery'), // Target the specific third-party library
          loader: 'imports-loader',
          options: {
            wrapper: 'window', // Execute the script in the window context
          },
        },
      ],
    },
  };
  

This wraps the library’s code in a self-executing function that uses window as its context, effectively attaching its variables to the global scope without any unsafe eval calls.

2. Inject Scripts via HTML (No Loader Required) #

If you don’t need to bundle the third-party script into your main bundle (e.g., for large libraries or CDN-hosted assets), this is the simplest CSP-compliant approach. Regular <script> tags automatically expose their variables to window and avoid any eval-related risks.

Setup Steps: #

• For local scripts, configure Webpack to copy them to your output directory using asset/resource:

  module.exports = {
    module: {
      rules: [
        {
          test: /path-to-your-script\.js$/,
          type: 'asset/resource',
          generator: {
            filename: 'scripts/[name].[hash].js',
          },
        },
      ],
    },
    plugins: [
      new HtmlWebpackPlugin({
        template: './src/index.html',
        scriptLoading: 'defer', // Adjust loading behavior as needed
      }),
    ],
  };
  

• Add a regular script tag to your HTML template (point to the local output path or a CDN URL):

  <script src="/scripts/your-third-party-script.js"></script>
  

3. Create a Custom Minimal Loader #

If you need full control over how scripts are attached to window (e.g., for niche or legacy scripts), writing a tiny custom loader is trivial and avoids external dependencies.

Setup Steps: #

• Create a file named global-loader.js in your project root:

  module.exports = function (source) {
    // Wrap the script in a function that executes in the window context
    return `(function(window) {
      ${source}
    })(window);`;
  };
  

• Use it in your Webpack config to target specific scripts:

  const path = require('path');
  
  module.exports = {
    module: {
      rules: [
        {
          test: /your-target-script\.js$/,
          loader: path.resolve('./global-loader.js'),
        },
      ],
    },
  };
  

This approach executes the script directly in the window scope without using eval, making it 100% compliant with strict CSP policies.

Key Advantages Over script-loader #

All these alternatives avoid the eval.call pattern that breaks CSP rules. They’re either actively maintained (imports-loader) or fully under your control (custom loader/HTML injection), so you don’t have to rely on a deprecated, unmaintained package.

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