Security & Maintenance Risk: No explicit Node.js target specified

By only setting esmodules: false without specifying a concrete Node.js version target, the transpilation behavior becomes less predictable and depends on Babel's default browserslist configuration. This can lead to:

1. Security risk: No explicit lower bound means the code may not transpile newer syntax that could cause runtime errors on older environments
2. Inconsistent builds: Different developers/CI environments might produce different output depending on their browserslist database version

While I understand from the review comments that you're keeping this approach to maintain ES2017 compatibility for the es-check validation, I recommend:

1. Either add an explicit node: '8.0' target (as discussed in comments) OR
2. Update the project to drop Node 8 support and set a modern target like node: '14', then update the es-check script accordingly

The current configuration creates an implicit dependency on browserslist defaults which reduces build reproducibility.

Pinning Cheerio Version: Why 0.22.0?

Cheerio 0.22.0 was released in 2017 and has known security vulnerabilities. Pinning to this specific old version raises concerns:

1. Security risk: Very old version likely contains unpatched vulnerabilities
2. Why this version?: The comment mentions "maintain compatibility" but doesn't specify what breaks with newer versions
3. Enzyme limitation: If this is required for [email protected] compatibility, it indicates enzyme itself may be outdated

Recommendation:

1. Document in a comment WHY this specific version is required
2. Investigate upgrading to React Testing Library instead of Enzyme (Enzyme is no longer actively maintained)
3. If keeping Enzyme, verify if newer cheerio versions work with enzyme 3.11.0

Node.js Specific Import in Browser Test Environment

Importing TextEncoder and TextDecoder from Node.js's util module in a browser-focused test environment (jsdom) is a workaround for missing globals.

Concerns:

1. Semantic mismatch: You're polyfilling browser APIs with Node.js implementations
2. Behavior differences: Node.js TextEncoder/TextDecoder may have subtle behavioral differences from browser implementations
3. Better alternatives: Consider using a proper polyfill package like text-encoding or fast-text-encoding that provides browser-compliant implementations

Recommendation:

// Instead of Node.js util, use a proper polyfill:
import { TextEncoder, TextDecoder } from 'text-encoding';

However, if this is working in practice and jest-environment-jsdom 30.x requires it, this is acceptable with a comment explaining why.