Skip to content

Commit dcfb44a

Browse files
committed
doc: add indexed Array.prototype properties to primordial exclusions
Signed-off-by: Renegade334 <contact.9a5d6388@renegade334.me.uk>
1 parent 18c2b33 commit dcfb44a

1 file changed

Lines changed: 23 additions & 1 deletion

File tree

‎doc/contributing/primordials.md‎

Lines changed: 23 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -105,7 +105,9 @@ There are some built-in functions that accept a variable number of arguments
105105
the list of arguments as an array. You can use primordial function with the
106106
suffix `Apply` (e.g.: `MathMaxApply`, `ArrayPrototypePushApply`) to do that.
107107

108-
## Primordials with known performance issues
108+
## Limitations and exclusions
109+
110+
### Primordials with known performance issues
109111

110112
One of the reasons why the current Node.js API is not completely tamper-proof is
111113
performance: sometimes the use of primordials can cause performance regressions
@@ -137,6 +139,26 @@ performance of code in Node.js.
137139
In general, when sending or reviewing a PR that makes changes in a hot code
138140
path, use extra caution and run extensive benchmarks.
139141

142+
### User-defined index properties on `Array.prototype`
143+
144+
A recurring theme in issues/PRs is that changing the behavior of indexed
145+
array properties via `Array.prototype` breaks a particular Node.js API.
146+
147+
<!-- eslint-disable accessor-pairs -->
148+
149+
```js
150+
Object.defineProperty(
151+
Array.prototype,
152+
'0',
153+
{ set() {} },
154+
);
155+
```
156+
157+
These patterns are expected to break both ECMAScript builtins and application
158+
code, and Node.js does not make any attempt to harden against them. To do so
159+
would necessitate using property descriptor methods for every single array
160+
interaction, which is not practical.
161+
140162
## Implicit use of user-mutable methods
141163

142164
### Unsafe array iteration

0 commit comments

Comments
 (0)