package.json currently declares deep-copy@^1.4.2 as a direct dev dependency. ts/test/test-heap-profiler.ts loads it with require('deep-copy') and uses it to clone the plain profile fixtures in the heap-profiler tests.
Would the maintainers approve replacing that declaration with an npm alias?
"deep-copy": "npm:@stackline/deep-copy@1.0.0"
The alias would preserve the existing import key and callable CommonJS API, so the test source would not need to change. The replacement supports the repository's Node >=18 range and has no production dependencies. I maintain @stackline/deep-copy; its package and compatibility documentation are available at https://www.npmjs.com/package/@stackline/deep-copy and https://alexandro.net/docs/vanilla/deep-copy/contract.html.
If this direction is acceptable, I can prepare the focused manifest/lockfile change and run the heap-profiler test suite. Keeping the current version or choosing another maintained compatible implementation are also reasonable alternatives if the project prefers them.
package.jsoncurrently declaresdeep-copy@^1.4.2as a direct dev dependency.ts/test/test-heap-profiler.tsloads it withrequire('deep-copy')and uses it to clone the plain profile fixtures in the heap-profiler tests.Would the maintainers approve replacing that declaration with an npm alias?
The alias would preserve the existing import key and callable CommonJS API, so the test source would not need to change. The replacement supports the repository's Node
>=18range and has no production dependencies. I maintain@stackline/deep-copy; its package and compatibility documentation are available at https://www.npmjs.com/package/@stackline/deep-copy and https://alexandro.net/docs/vanilla/deep-copy/contract.html.If this direction is acceptable, I can prepare the focused manifest/lockfile change and run the heap-profiler test suite. Keeping the current version or choosing another maintained compatible implementation are also reasonable alternatives if the project prefers them.