How to validate backup and restore processes for core-js polyfills?

Answer the exact question first

To confirm that a restored core-js polyfill set behaves exactly as before, perform a two‑phase validation:

1. Integrity check: Verify that the backup archive contains the exact files that were originally installed. Compute a SHA‑256 hash of the node_modules/core-js directory (or the bundled file if you use a custom build) and compare it to a stored hash. If you archived package.json and package-lock.json, also hash those files to guard against accidental version drift.
2. Behavioral test: After restoring, run a feature‑detection script that enumerates all exported polyfills and compares the result to a pre‑backup manifest. Then execute your project’s full test suite, ensuring that any tests relying on polyfilled features still pass.

Confirmed facts

• Core‑js must be pinned in package.json and the lockfile; mismatched versions change polyfill semantics.
• Tree‑shaking can drop unused polyfills, so a full source backup is required if your build relies on the entire library.
• Node and browser targets may need different polyfill sets; the environment must be identified before backup.
• If a custom build (e.g., core-js-pure) is used, the build configuration and output bundle must be archived and verified.
• The backup process should record the npm package digest or commit hash to prevent accidental upgrades.

Steps for an automated validation suite

1. Generate a manifest (before backup):

   const core = require('core-js');
   const fs = require('fs');
   const manifest = Object.keys(core).sort();
   fs.writeFileSync('corejs-manifest.json', JSON.stringify(manifest, null, 2));
   

2. Compute checksums:

   npm run hash:corejs # custom script that zips node_modules/core-js and outputs SHA‑256
   

3. Archive the node_modules/core-js directory, package.json, package-lock.json, and the manifest.
4. Restore by deleting node_modules and running npm ci (or npm install if lockfile is absent).
5. Re‑generate the manifest after restore and compare byte‑by‑byte to the stored file.
6. Run the full test suite – any failing test that depends on a polyfilled API signals a regression.

Isolating the restored library

• Temporary sandbox project: Create a new Node project, copy the restored node_modules/core-js into it, and run the feature‑detection script there. This guarantees no interference from other dependencies.
• Module aliasing: In a test file, use module-alias to point core-js to the restored path:

  require('module-alias/register');
  require('module-alias').addAlias('core-js', '/path/to/restored/node_modules/core-js');
  const core = require('core-js');
  

• Environment variable override: If you bundle with Webpack, set process.env.CORE_JS_PATH and adjust the resolver to use that path during tests.

What automated test suite to use?

For the most thorough check, combine a lightweight feature‑detection script (as shown above) with your existing unit test runner (Jest, Mocha, etc.). If you need stricter conformance, consider running the official core-js test harness (npm i -g core-js@next and core-js test) against the restored copy. This harness exercises each polyfill against its spec.

Ask for missing diagnostic detail

Do you use core-js-pure or a custom build configuration? Knowing that will determine whether you need to archive the build script and output bundle, in addition to the source.