fix: shadow global Symbol in async-iterator to resolve lint#11905
Draft
Planeshifter wants to merge 1 commit intodevelopfrom
Draft
fix: shadow global Symbol in async-iterator to resolve lint#11905Planeshifter wants to merge 1 commit intodevelopfrom
Planeshifter wants to merge 1 commit intodevelopfrom
Conversation
The CI JavaScript lint job on develop has been failing since 2026-05-01: symbol/async-iterator/lib/main.js 42:65 error The 'Symbol.asyncIterator' is still an experimental feature and is not supported until Node.js 10.0.0. (n/no-unsupported-features/es-builtins) Root cause: the file references the global `Symbol.asyncIterator` directly. The `n/no-unsupported-features/es-builtins` rule flags any global `Symbol.*` access when the configured engine range (`>=0.12.18`) predates Node.js 10. Adding a local `var Symbol = require( '@stdlib/symbol/ctor' )` shadows the global, resolving the rule without altering runtime behavior (the `hasAsyncIteratorSymbolSupport()` guard already short-circuits the ternary on environments where the local Symbol would be undefined). This pattern is identical to `@stdlib/symbol/to-primitive` (line 24). Failing run: https://github.com/stdlib-js/stdlib/actions/runs/25195861572
Contributor
Coverage Report
The above coverage report was generated for the changes in this PR. |
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Failing run: https://github.com/stdlib-js/stdlib/actions/runs/25195861572 (issue #11867, 2026-05-01)
Symptom:
Root cause:
eslint-plugin-n'sno-unsupported-features/es-builtinsrule flags any globalSymbol.*property access when the package'sengines.noderange predates the Node.js version that introduced that property. The package declares>=0.12.18, butSymbol.asyncIteratorrequires Node ≥ 10. Because no localSymbolbinding existed in the file, the rule saw the global and triggered.Fix:
Add
var Symbol = require( '@stdlib/symbol/ctor' );to the// MODULES //section. A local binding namedSymbolshadows the global; the rule no longer applies its version check toSymbol.asyncIterator. Runtime behavior is unchanged —hasAsyncIteratorSymbolSupport()already guards the ternary, so theSymbol.asyncIteratorproperty is never evaluated in environments where the stdlib Symbol polyfill would returnundefined. This is the identical pattern used in@stdlib/symbol/to-primitive(line 24 of itslib/main.js).Validation:
@stdlib/symbol/to-primitive/lib/main.jsexactly.@stdlib/symbol/async-iterator/package.jsonhas emptydependencies: {}; this matches the established sibling pattern (to-primitivealso has empty deps but requires@stdlib/symbol/ctor).hasAsyncIteratorSymbolSupport()guard prevents any runtime error in environments where ctor returnsundefined; only oneSymbol.*reference in the file.Reviewer notes:
@stdlib/symbol/ctorreturnsvoid 0(notnull) on Symbol-unsupported environments; the brief's description saidnull. This is a documentation inaccuracy in the brief only — runtime behavior is correct because the guard prevents the property access.Related: issue #11867 (cluster 2 of that issue —
utils/constructor-name— is addressed in a separate draft PR)Contributing Guidelines
Generated by Claude Code