💻
How are you using Babel?
Other (Next.js, Gatsby, vue-cli, ...)
Input code
import '@endo/init'
import chalk, { Chalk as ChalkClass } from "chalk@2.4.2";
REPL
Configuration file name
No response
Configuration
No response
Current and expected behavior
When copying props of module.exports to newObj, interopRequireWildcard may use a simple assignment =, which may trigger the override mistake for exported properties also present in Object.prototype if Object.prototype had previously been frozen.
In this case the chalk package used by @babel/code-frame and @babel/highlights in the latest 7.22.20 version of babel triggers this issue with its constructor export.
Environment
System:
OS: Linux 5.10 Debian GNU/Linux 11 (bullseye) 11 (bullseye)
Binaries:
Node: 18.17.0 - /usr/local/bin/node
Yarn: 1.22.5 - /usr/local/bin/yarn
npm: 9.8.1 - /usr/local/bin/npm
pnpm: 8.6.11 - /usr/local/share/npm-global/bin/pnpm
Monorepos:
Yarn Workspaces: 1.22.5
npmPackages:
eslint: ^8.36.0 => 8.50.0
Possible solution
In this case there may be different alternatives to avoid triggering the override mistake:
- make
newObj with a null proto
- Use
Object.defineProperty in all cases (not just for accessors)
Additional context
@nicolo-ribaudo will know the context :)
💻
How are you using Babel?
Other (Next.js, Gatsby, vue-cli, ...)
Input code
REPL
Configuration file name
No response
Configuration
No response
Current and expected behavior
When copying props of
module.exportstonewObj,interopRequireWildcardmay use a simple assignment=, which may trigger the override mistake for exported properties also present inObject.prototypeifObject.prototypehad previously been frozen.In this case the
chalkpackage used by@babel/code-frameand@babel/highlightsin the latest 7.22.20 version of babel triggers this issue with itsconstructorexport.Environment
System:
OS: Linux 5.10 Debian GNU/Linux 11 (bullseye) 11 (bullseye)
Binaries:
Node: 18.17.0 - /usr/local/bin/node
Yarn: 1.22.5 - /usr/local/bin/yarn
npm: 9.8.1 - /usr/local/bin/npm
pnpm: 8.6.11 - /usr/local/share/npm-global/bin/pnpm
Monorepos:
Yarn Workspaces: 1.22.5
npmPackages:
eslint: ^8.36.0 => 8.50.0
Possible solution
In this case there may be different alternatives to avoid triggering the override mistake:
newObjwith anullprotoObject.definePropertyin all cases (not just for accessors)Additional context
@nicolo-ribaudo will know the context :)