-
-
Notifications
You must be signed in to change notification settings - Fork 307
[New] add types #603
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
[New] add types #603
Conversation
Are these hand written or generated from JSDoc ? It's unclear to me. Either way looks reasonable to me. |
Hand-written. |
This comment was marked as outdated.
This comment was marked as outdated.
54b4f2d
to
decd5d2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool to see this addition - thanks for mentioning it!
I can take a deeper look if the tsc
having a lot of errors already thing isn't a blocker.
Thanks, I've updated the PR and gotten it down to 4 errors (i swear it was at zero when I put up the PR :-p) I'd love to get suggestions for those. |
Oop, sorry for taking so long - I'd added this tab on my phone and forgot about it 😅. Looking now!
On the latest commit I get no errors. So, nicely done! 😄 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great!
Left some suggestions, but nothing showing anything wrong. Nicely done! 👏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might consider also porting in the types tests from https://github.com/DefinitelyTyped/DefinitelyTyped/blob/e1386bb7838c35504edfdb12876bf0d156d84a2a/types/tap/tap-tests.ts. Since the .d.ts
is being hand-written rather than auto-generated from source files, it wouldn't be unheard of for it to fall out of sync.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if it were out of sync, wouldn't tsc
fail?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not in all cases. If you, say, added an extra optional parameter somewhere but never used it, tsc
wouldn't think to fail on it.
lib/test.js
Outdated
Test.prototype['throws'] = function (fn, expected, msg, extra) { | ||
if (typeof expected === 'string') { | ||
msg = expected; | ||
expected = undefined; | ||
} | ||
|
||
/** @type {undefined | { error: unknown | Error }} */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
error: unknown | Error
is equivalent to error: unknown
. unknown
is a top type indicating it could be anything in the world, including Error
. plugin:@typescript-eslint/no-redundant-type-constituents
The code later on just checks if (caught.error && typeof caught.error === 'object')
, not instanceof Error
or an equivalent. So if a caught.error
is a non-Error
object, the assumption it could be an Error
would be wrong.
Can caught.error
be something other than Error
? If so, what?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
technically line 897 doesn't ensure it's an Error, but if that branch is entered, then it's so Error-like as to not make a difference. there doesn't seem to be any way i can do a type assertion without runtime code :-/
lib/test.js
Outdated
// TS TODO: `caught.error` and `expected` should both be `object` here | ||
passed = every(keys, /** @type {(key: PropertyKey) => boolean} */ function (key) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, TypeScript doesn't have a way of being informed that every
's callbacks should keep narrowing. A type assertion would be the appropriate thing to do here instead of // @ts-expect-error
to avoid changing runtime code.
A small runtime change could be to store error
and expected
as variables after narrowing them.
Alternately, the next version of TypeScript might be nicer about preserving narrowings - I haven't tried.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm using next
, so it doesn't help me here. this isn't TS-expect-error tho; it's just a TODO comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant the // @ts-expect-error
s later.
c16dde3
to
2ad86d4
Compare
92aa51c
to
e80d128
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #603 +/- ##
==========================================
- Coverage 96.59% 96.15% -0.44%
==========================================
Files 4 5 +1
Lines 764 781 +17
Branches 194 197 +3
==========================================
+ Hits 738 751 +13
- Misses 26 30 +4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
@andrewbranch attw is failing with "named exports" as of 0.17, and I can't figure out what i could change to make it pass. any tips? |
@ljharb can you point me to the failure message in CI? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (6)
test/intercept.js (3)
19-19
: Add clarification to the error suppression commentThe comment
// @ts-expect-error TS sucks with concat
could be more professional and descriptive of the actual issue. Consider changing it to explain the specific type issue with array concatenation.-// @ts-expect-error TS sucks with concat +// @ts-expect-error TypeScript has issues with array concatenation of heterogeneous types
152-153
: Consider using a more specific type for object propertiesWhile
Record<PropertyKey, unknown>
works, you might consider using a more specific type that describes the expected structure of the object, including thefoo
property and theinspect
method.-/** @type {Record<PropertyKey, unknown>} */ +/** @type {{ foo: unknown, inspect(): string} & Record<PropertyKey, unknown>} */
245-246
: Consider a more specific type for the 'val' variableUsing
unknown
is safer thanany
, but since this variable will only store values set to thesetter
property, you could consider using a more specific type or adding a comment explaining its purpose.-/** @type {unknown} */ +/** + * @type {unknown} + * Stores the value set by the setter property + */index.d.ts (1)
6-20
: Consider unifying harnessFunction overloads.Multiple overloads can be harder to maintain. It might be tidier to provide one or two broader overloads and make parameters optional, if feasible.
lib/test.js (2)
59-80
: Consider simplifying argument parsing ingetTestArgs
.Using multiple argument types in a loop is functional, but you could consider a single parameter object or other patterns for more straightforward type definitions.
120-125
: Offer assistance with@ts-expect-error
usage.There's a
// @ts-expect-error
hint at line 122. If you need help refining the type so this directive can be removed or replaced with a safer assertion, let me know.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
.github/workflows/node-aught.yml
is excluded by!**/*.yml
package.json
is excluded by!**/*.json
tsconfig.json
is excluded by!**/*.json
📒 Files selected for processing (81)
.eslintrc
(1 hunks)bin/import-or-require.js
(1 hunks)bin/tape
(2 hunks)example/array.js
(2 hunks)example/fail.js
(2 hunks)example/nested.js
(2 hunks)example/nested_fail.js
(2 hunks)example/not_enough_fail.js
(2 hunks)example/too_many_fail.js
(2 hunks)index.d.ts
(1 hunks)index.js
(8 hunks)lib/default_stream.d.ts
(1 hunks)lib/default_stream.js
(2 hunks)lib/isObject.js
(1 hunks)lib/results.d.ts
(1 hunks)lib/results.js
(9 hunks)lib/test.d.ts
(1 hunks)lib/test.js
(42 hunks)test/anonymous-fn/test-wrapper.js
(1 hunks)test/array.js
(2 hunks)test/assertion.js
(4 hunks)test/async-await.js
(2 hunks)test/async-await/async-bug.js
(3 hunks)test/async-await/async4.js
(1 hunks)test/async-await/async5.js
(3 hunks)test/capture.js
(6 hunks)test/captureFn.js
(3 hunks)test/comment.js
(4 hunks)test/common.js
(6 hunks)test/deep-equal-failure.js
(3 hunks)test/deep.js
(1 hunks)test/default_stream.js
(1 hunks)test/double_end.js
(2 hunks)test/end-as-callback.js
(2 hunks)test/exit.js
(7 hunks)test/exit/fail.js
(2 hunks)test/exit/ok.js
(2 hunks)test/exit/too_few.js
(2 hunks)test/fail.js
(2 hunks)test/ignore-pattern.js
(3 hunks)test/ignore_from_gitignore.js
(4 hunks)test/import.js
(4 hunks)test/import/mjs-a.mjs
(1 hunks)test/import/mjs-b.mjs
(1 hunks)test/import/mjs-c.mjs
(1 hunks)test/import/mjs-d.mjs
(1 hunks)test/import/mjs-e.mjs
(1 hunks)test/import/mjs-f.mjs
(1 hunks)test/import/mjs-g.mjs
(1 hunks)test/import/mjs-h.mjs
(1 hunks)test/import/package_type/package-a.js
(1 hunks)test/import/package_type/package-b.js
(1 hunks)test/import/package_type/package-c.js
(1 hunks)test/intercept.js
(11 hunks)test/match.js
(2 hunks)test/max_listeners.js
(1 hunks)test/nested.js
(2 hunks)test/no_only.js
(3 hunks)test/not-deep-equal-failure.js
(3 hunks)test/objectMode.js
(2 hunks)test/objectModeWithComment.js
(2 hunks)test/onFailure.js
(1 hunks)test/only.js
(1 hunks)test/promises/fail.js
(1 hunks)test/promises/subTests.js
(1 hunks)test/require.js
(3 hunks)test/require/a.js
(1 hunks)test/require/b.js
(1 hunks)test/require/test-a.js
(1 hunks)test/require/test-b.js
(1 hunks)test/skip.js
(1 hunks)test/stackTrace.js
(15 hunks)test/strict.js
(1 hunks)test/subtest_and_async.js
(1 hunks)test/teardown.js
(5 hunks)test/throws.js
(6 hunks)test/timeoutAfter.js
(1 hunks)test/todo.js
(1 hunks)test/too_many.js
(2 hunks)types/ecstatic/index.d.ts
(1 hunks)types/tap-parser/index.d.ts
(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (73)
- test/require/test-a.js
- test/async-await/async4.js
- test/promises/fail.js
- test/promises/subTests.js
- test/import/package_type/package-c.js
- test/import/mjs-a.mjs
- test/require/test-b.js
- test/import/mjs-h.mjs
- test/anonymous-fn/test-wrapper.js
- test/import/package_type/package-a.js
- test/import/mjs-g.mjs
- test/skip.js
- test/subtest_and_async.js
- test/only.js
- .eslintrc
- test/import/mjs-b.mjs
- test/import/package_type/package-b.js
- test/require/b.js
- test/ignore-pattern.js
- test/timeoutAfter.js
- bin/import-or-require.js
- test/exit.js
- test/import/mjs-c.mjs
- lib/default_stream.d.ts
- test/onFailure.js
- test/async-await/async5.js
- test/deep.js
- test/captureFn.js
- test/require.js
- test/require/a.js
- test/import/mjs-e.mjs
- types/ecstatic/index.d.ts
- test/too_many.js
- test/default_stream.js
- test/async-await.js
- test/import/mjs-f.mjs
- test/max_listeners.js
- test/todo.js
- test/exit/ok.js
- test/capture.js
- test/ignore_from_gitignore.js
- test/array.js
- test/exit/fail.js
- example/array.js
- bin/tape
- test/teardown.js
- lib/default_stream.js
- example/not_enough_fail.js
- test/nested.js
- example/too_many_fail.js
- test/import/mjs-d.mjs
- test/strict.js
- example/nested_fail.js
- test/double_end.js
- example/fail.js
- test/throws.js
- test/match.js
- test/exit/too_few.js
- test/objectMode.js
- test/common.js
- test/deep-equal-failure.js
- test/assertion.js
- example/nested.js
- test/fail.js
- test/objectModeWithComment.js
- test/stackTrace.js
- test/end-as-callback.js
- test/not-deep-equal-failure.js
- types/tap-parser/index.d.ts
- test/async-await/async-bug.js
- test/import.js
- lib/results.js
- test/comment.js
🧰 Additional context used
🧠 Learnings (6)
lib/results.d.ts (1)
Learnt from: ljharb
PR: tape-testing/tape#603
File: lib/results.d.ts:18-20
Timestamp: 2024-11-27T00:54:06.607Z
Learning: Do not suggest adding the `private` modifier to properties and methods in TypeScript code, as `private` is not part of standard JavaScript. Avoid recommending the use of the `private` keyword in code reviews for TypeScript projects.
index.d.ts (2)
Learnt from: ljharb
PR: tape-testing/tape#603
File: index.d.ts:68-70
Timestamp: 2024-11-27T00:58:49.749Z
Learning: In a `.d.ts` file, it's acceptable to declare constants of types imported with `import type`, because type and value spaces are separate.
Learnt from: ljharb
PR: tape-testing/tape#603
File: index.js:142-143
Timestamp: 2025-02-06T20:57:58.411Z
Learning: In tape's index.js, the test function returned by createHarness implements all Harness type properties: only, close, createStream, onFinish, onFailure, _tests, _exitCode, and _results. The run property is optional.
lib/test.js (1)
Learnt from: ljharb
PR: tape-testing/tape#603
File: lib/test.js:0-0
Timestamp: 2024-11-12T06:00:40.803Z
Learning: The project `tape-testing/tape` uses ES3 syntax only and does not use TypeScript as a language. However, it employs the TypeScript Compiler (tsc) for type checking JavaScript files. This distinction is crucial for understanding the project's approach to handling types and syntax.
lib/test.d.ts (7)
Learnt from: ljharb
PR: tape-testing/tape#603
File: lib/test.d.ts:14-20
Timestamp: 2024-11-12T06:00:40.803Z
Learning: When suggesting changes to constructor overloads in TypeScript, ensure that all possible argument combinations are covered, including the option for a single callback argument.
Learnt from: ljharb
PR: tape-testing/tape#603
File: lib/test.d.ts:198-198
Timestamp: 2024-11-27T00:56:04.598Z
Learning: In this codebase, using `{}` as a type for the `receiver` property is intentional to allow primitives as receivers because `unknown` is invalid in this context.
Learnt from: ljharb
PR: tape-testing/tape#603
File: lib/test.d.ts:112-112
Timestamp: 2024-11-27T00:57:05.043Z
Learning: In `lib/test.d.ts`, for the `throws` method's `exceptionExpected` parameter, using `Function` as a type is correct and should not be replaced with `ErrorConstructor`, as it avoids introducing bugs.
Learnt from: ljharb
PR: tape-testing/tape#603
File: lib/test.d.ts:126-126
Timestamp: 2024-11-27T00:56:43.820Z
Learning: In the TypeScript declarations in `lib/test.d.ts`, for the `throws` method in the `Test` class, the `exceptionExpected` parameter intentionally uses the `Function` type to accept any function-like value. Replacing it with `ErrorConstructor` is not appropriate in this context.
Learnt from: ljharb
PR: tape-testing/tape#603
File: lib/test.d.ts:192-192
Timestamp: 2024-11-27T00:56:52.796Z
Learning: In `lib/test.d.ts`, it's acceptable to use `{}` as the type for the `receiver` property.
Learnt from: ljharb
PR: tape-testing/tape#603
File: lib/test.d.ts:172-172
Timestamp: 2025-02-06T18:06:43.090Z
Learning: In TypeScript, trailing commas after rest parameters are allowed specifically in .d.ts files (ambient contexts) as an exception to the normal syntax rules, even though they would trigger TS1013 errors in regular TypeScript files.
Learnt from: ljharb
PR: tape-testing/tape#603
File: lib/test.d.ts:172-172
Timestamp: 2025-02-06T18:06:43.090Z
Learning: Trailing commas are allowed in rest parameters and other locations in TypeScript declaration files (.d.ts), unlike JavaScript files.
index.js (3)
Learnt from: ljharb
PR: tape-testing/tape#603
File: index.js:147-147
Timestamp: 2024-11-12T06:00:40.803Z
Learning: Comments in the codebase should focus on explaining "why" or providing history/motivation, rather than detailing "what" the code does, as per ljharb's guidance.
Learnt from: ljharb
PR: tape-testing/tape#603
File: index.js:142-143
Timestamp: 2025-02-06T20:57:58.411Z
Learning: In tape's index.js, the test function returned by createHarness implements all Harness type properties: only, close, createStream, onFinish, onFailure, _tests, _exitCode, and _results. The run property is optional.
Learnt from: ljharb
PR: tape-testing/tape#603
File: index.js:211-224
Timestamp: 2025-02-10T20:24:25.187Z
Learning: In the tape module, module.exports is a function that must be mutated with additional properties. Using an object literal or Object.assign would either break functionality or add unnecessary dependencies.
test/no_only.js (1)
Learnt from: ljharb
PR: tape-testing/tape#603
File: test/no_only.js:47-47
Timestamp: 2025-03-03T23:09:11.191Z
Learning: The tape-testing repository uses ES3 syntax, which means modern JavaScript features like optional chaining (?.) cannot be used.
🪛 Biome (1.9.4)
index.d.ts
[error] 85-85: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 86-86: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 87-87: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 88-88: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 89-89: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 90-90: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
lib/test.d.ts
[error] 179-179: rest elements may not have trailing commas
(parse)
[error] 40-40: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 44-44: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 49-49: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 50-50: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 52-52: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 58-58: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 59-59: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 61-61: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 64-64: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 65-65: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 66-66: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 67-67: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 69-69: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 70-70: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 71-71: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 72-72: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 73-73: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 77-77: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 81-81: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 85-85: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 90-90: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 97-97: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 107-107: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 110-110: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 113-113: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 118-118: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 128-128: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 130-130: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 133-133: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 140-140: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 147-147: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 154-154: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 161-161: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 169-169: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 177-177: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 149-149: Don't use 'Function' as a type.
Prefer explicitly define the function shape. This type accepts any function-like value, which can be a common source of bugs.
(lint/complexity/noBannedTypes)
index.js
[error] 131-131: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
test/no_only.js
[error] 27-27: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
⏰ Context from checks skipped due to timeout of 90000ms (200)
- GitHub Check: tests / pack
- GitHub Check: tests / latest (19.9)
- GitHub Check: tests / latest (18.20)
- GitHub Check: tests / latest (vlt i) (22.14)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (0.8)
- GitHub Check: tests / latest (2.5)
- GitHub Check: tests / latest (1.8)
- GitHub Check: tests / latest (3.3)
- GitHub Check: tests / latest (6.17)
- GitHub Check: tests / latest (0.12)
- GitHub Check: tests / latest (4.9)
- GitHub Check: tests / latest (8.17)
- GitHub Check: tests / latest (9.11)
- GitHub Check: tests / latest (5.12)
- GitHub Check: tests / latest (7.10)
- GitHub Check: tests / latest (0.10)
- GitHub Check: tests / latest (23.9)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (13.14)
- GitHub Check: tests / pack
- GitHub Check: tests / latest (19.9)
- GitHub Check: tests / latest (18.20)
- GitHub Check: tests / latest (vlt i) (22.14)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (0.8)
- GitHub Check: tests / latest (2.5)
- GitHub Check: tests / latest (1.8)
- GitHub Check: tests / latest (3.3)
- GitHub Check: tests / latest (6.17)
- GitHub Check: tests / latest (0.12)
- GitHub Check: tests / latest (4.9)
- GitHub Check: tests / latest (8.17)
- GitHub Check: tests / latest (9.11)
- GitHub Check: tests / latest (5.12)
- GitHub Check: tests / latest (7.10)
- GitHub Check: tests / latest (0.10)
- GitHub Check: tests / latest (23.9)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (13.14)
- GitHub Check: tests / pack
- GitHub Check: tests / latest (19.9)
- GitHub Check: tests / latest (18.20)
- GitHub Check: tests / latest (vlt i) (22.14)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (0.8)
- GitHub Check: tests / latest (2.5)
- GitHub Check: tests / latest (1.8)
- GitHub Check: tests / latest (3.3)
- GitHub Check: tests / latest (6.17)
- GitHub Check: tests / latest (0.12)
- GitHub Check: tests / latest (4.9)
- GitHub Check: tests / latest (8.17)
- GitHub Check: tests / latest (9.11)
- GitHub Check: tests / latest (5.12)
- GitHub Check: tests / latest (7.10)
- GitHub Check: tests / latest (0.10)
- GitHub Check: tests / latest (23.9)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (13.14)
- GitHub Check: tests / pack
- GitHub Check: tests / latest (19.9)
- GitHub Check: tests / latest (18.20)
- GitHub Check: tests / latest (vlt i) (22.14)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (0.8)
- GitHub Check: tests / latest (2.5)
- GitHub Check: tests / latest (1.8)
- GitHub Check: tests / latest (3.3)
- GitHub Check: tests / latest (6.17)
- GitHub Check: tests / latest (0.12)
- GitHub Check: tests / latest (4.9)
- GitHub Check: tests / latest (8.17)
- GitHub Check: tests / latest (9.11)
- GitHub Check: tests / latest (5.12)
- GitHub Check: tests / latest (7.10)
- GitHub Check: tests / latest (0.10)
- GitHub Check: tests / latest (23.9)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (13.14)
- GitHub Check: tests / pack
- GitHub Check: tests / latest (19.9)
- GitHub Check: tests / latest (18.20)
- GitHub Check: tests / latest (vlt i) (22.14)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (0.8)
- GitHub Check: tests / latest (2.5)
- GitHub Check: tests / latest (1.8)
- GitHub Check: tests / latest (3.3)
- GitHub Check: tests / latest (6.17)
- GitHub Check: tests / latest (0.12)
- GitHub Check: tests / latest (4.9)
- GitHub Check: tests / latest (8.17)
- GitHub Check: tests / latest (9.11)
- GitHub Check: tests / latest (5.12)
- GitHub Check: tests / latest (7.10)
- GitHub Check: tests / latest (0.10)
- GitHub Check: tests / latest (23.9)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (13.14)
- GitHub Check: tests / pack
- GitHub Check: tests / latest (19.9)
- GitHub Check: tests / latest (18.20)
- GitHub Check: tests / latest (vlt i) (22.14)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (0.8)
- GitHub Check: tests / latest (2.5)
- GitHub Check: tests / latest (1.8)
- GitHub Check: tests / latest (3.3)
- GitHub Check: tests / latest (6.17)
- GitHub Check: tests / latest (0.12)
- GitHub Check: tests / latest (4.9)
- GitHub Check: tests / latest (8.17)
- GitHub Check: tests / latest (9.11)
- GitHub Check: tests / latest (5.12)
- GitHub Check: tests / latest (7.10)
- GitHub Check: tests / latest (0.10)
- GitHub Check: tests / latest (23.9)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (13.14)
- GitHub Check: tests / pack
- GitHub Check: tests / latest (19.9)
- GitHub Check: tests / latest (18.20)
- GitHub Check: tests / latest (vlt i) (22.14)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (0.8)
- GitHub Check: tests / latest (2.5)
- GitHub Check: tests / latest (1.8)
- GitHub Check: tests / latest (3.3)
- GitHub Check: tests / latest (6.17)
- GitHub Check: tests / latest (0.12)
- GitHub Check: tests / latest (4.9)
- GitHub Check: tests / latest (8.17)
- GitHub Check: tests / latest (9.11)
- GitHub Check: tests / latest (5.12)
- GitHub Check: tests / latest (7.10)
- GitHub Check: tests / latest (0.10)
- GitHub Check: tests / latest (23.9)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (13.14)
- GitHub Check: tests / pack
- GitHub Check: tests / latest (19.9)
- GitHub Check: tests / latest (18.20)
- GitHub Check: tests / latest (vlt i) (22.14)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (0.8)
- GitHub Check: tests / latest (2.5)
- GitHub Check: tests / latest (1.8)
- GitHub Check: tests / latest (3.3)
- GitHub Check: tests / latest (6.17)
- GitHub Check: tests / latest (0.12)
- GitHub Check: tests / latest (4.9)
- GitHub Check: tests / latest (8.17)
- GitHub Check: tests / latest (9.11)
- GitHub Check: tests / latest (5.12)
- GitHub Check: tests / latest (7.10)
- GitHub Check: tests / latest (0.10)
- GitHub Check: tests / latest (23.9)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (13.14)
- GitHub Check: tests / pack
- GitHub Check: tests / latest (19.9)
- GitHub Check: tests / latest (18.20)
- GitHub Check: tests / latest (vlt i) (22.14)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (0.8)
- GitHub Check: tests / latest (2.5)
- GitHub Check: tests / latest (1.8)
- GitHub Check: tests / latest (3.3)
- GitHub Check: tests / latest (6.17)
- GitHub Check: tests / latest (0.12)
- GitHub Check: tests / latest (4.9)
- GitHub Check: tests / latest (8.17)
- GitHub Check: tests / latest (9.11)
- GitHub Check: tests / latest (5.12)
- GitHub Check: tests / latest (7.10)
- GitHub Check: tests / latest (0.10)
- GitHub Check: tests / latest (23.9)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (13.14)
- GitHub Check: tests / pack
- GitHub Check: tests / latest (19.9)
- GitHub Check: tests / latest (18.20)
- GitHub Check: tests / latest (vlt i) (22.14)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (0.8)
- GitHub Check: tests / latest (2.5)
- GitHub Check: tests / latest (1.8)
- GitHub Check: tests / latest (3.3)
- GitHub Check: tests / latest (6.17)
- GitHub Check: tests / latest (0.12)
- GitHub Check: tests / latest (4.9)
- GitHub Check: tests / latest (8.17)
- GitHub Check: tests / latest (9.11)
- GitHub Check: tests / latest (5.12)
- GitHub Check: tests / latest (7.10)
- GitHub Check: tests / latest (0.10)
- GitHub Check: tests / latest (23.9)
- GitHub Check: tests / latest (vlt i) (23.9)
- GitHub Check: tests / latest (13.14)
🔇 Additional comments (26)
test/intercept.js (3)
94-98
: Good use of @ts-expect-error for intentional errorsThe use of
@ts-expect-error
annotations is appropriate here since these tests intentionally pass invalid arguments to verify error handling behavior. This allows the tests to continue functioning correctly while providing type safety elsewhere.Also applies to: 103-108, 112-117, 119-123, 137-142, 211-215, 228-232
147-148
: Well-defined custom type definitionsThese type definitions extend
PropertyDescriptor
with appropriate accessor methods, making it clear what properties are expected and improving type safety when accessing these methods later in the code.
163-166
: Good use of type assertions for property descriptorsThe type assertions for property descriptors ensure type safety when accessing
get
andset
methods. This is particularly important for the.call()
invocations that might otherwise cause type errors.Also applies to: 173-176, 242-242, 253-253
lib/isObject.js (1)
3-3
: Well-defined type predicate annotation.The JSDoc type annotation clearly defines that this function takes an unknown input and returns a type predicate. This is perfect for type narrowing in TypeScript environments and maintains backward compatibility with JavaScript.
test/no_only.js (3)
32-32
: Good addition of the ExecError type definition.This type definition enhances code clarity by correctly typing the error object with its optional code property.
47-47
: Inconsistent error handling pattern compared to line 27.Line 27 checks if
err
exists before accessing its code property (err && err.code
), while here you're using a type assertion without the null check.Consider using a consistent approach across the file:
- tt.equal(/** @type {ExecError} */ (err).code, expectedExitCodeOnError); + tt.equal(err && /** @type {ExecError} */ (err).code, expectedExitCodeOnError);
65-65
: Same inconsistent error handling pattern as line 47.Similar to line 47, this code lacks a null check before accessing the
code
property, unlike line 27 which includes this safety check.Consider using a consistent approach:
- tt.equal(/** @type {ExecError} */ (err).code, expectedExitCodeOnError); + tt.equal(err && /** @type {ExecError} */ (err).code, expectedExitCodeOnError);index.js (5)
11-11
: Good type assertion for browser property.The type assertion
/** @type {{ browser?: boolean }} */
properly handles the optional browser property on the process object.
15-24
: Well-organized type definitions.These typedef imports are well-structured and provide a clear reference to all the types used throughout the file.
141-142
: Type compatibility issue betweentest
andHarness
.The
@ts-expect-error
comment indicates a type compatibility issue between thetest
function and theHarness
type. Based on the retrieved learnings, the test function should implement all Harness properties.Double-check that all required Harness properties are implemented on the test function. If they are, this might be a TypeScript limitation with function types that also have properties.
163-163
: Good type assertion for stream piping.The type assertion
/** @type {NodeJS.WritableStream} */
ensures correct type compatibility when piping streams.
211-224
: Module exports pattern maintains function compatibility.The use of
@ts-expect-error
comments for module exports is necessary because the module.exports object is a function that must be mutated with additional properties.This approach is preferred over alternatives like object literals or Object.assign that would either break functionality or add unnecessary dependencies.
lib/results.d.ts (4)
1-6
: Well-structured imports.The import statements are organized logically, with external dependencies first followed by internal imports.
18-20
: Appropriate use of underscore prefix for internal properties.The properties
_isRunning
,_only
, and_stream
are correctly prefixed with underscore to indicate they're intended for internal use, while avoiding TypeScript-specific modifiers likeprivate
.
22-27
: Explicitthis
parameter in method declarations.The explicit
this: Results
parameter in method declarations is necessary for proper JSDoc importing of these method types.
33-51
: Comprehensive Result type definition.The Result type includes all necessary properties for test results, including both required and optional fields. The addition of the
test
andtype
properties enhances the type's functionality.index.d.ts (2)
22-45
: Namespace structure looks solid.The
tape
namespace is well-organized and coherently groups related types. No issues noted.
85-91
: Verify intentional usage ofvoid
in thethis
union.Some static analysis tools flag
void
as confusing in a union type. If it's needed to represent "no bound context," then it's valid. Otherwise, consider usingundefined
.🧰 Tools
🪛 Biome (1.9.4)
[error] 85-85: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 86-86: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 87-87: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 88-88: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 89-89: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 90-90: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
lib/test.js (4)
37-57
: Type definitions for error constructors look correct.The approach checks each known error constructor, which is especially helpful for older environments. No concerns here.
82-91
: Constructor pattern is consistent with typical factory usage.The constructor re-invokes itself when missing
new
, ensuring it always returns an instance. This is fine given the project's style.
880-957
:throws
method covers various error-check scenarios thoroughly.Supporting functions, objects, and RegEx expectations is flexible. The logic is carefully handled, including object key comparisons. Well-structured.
🧰 Tools
🪛 Biome (1.9.4)
[error] 897-897: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 952-952: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
1057-1064
: Skip implementation aligns with the existing interface.It marks tests as skipped by setting the
skip
option internally. This matches the module’s design choices.lib/test.d.ts (4)
14-18
: Constructor overloads account for various valid argument patterns.This preserves flexibility for test instantiation (name, options, callback, etc.). Looks aligned with user needs.
39-48
: Retainingvoid | Test
for thethis
parameter.Static analysis may complain about
void
in union types, but if your code expects no bound context sometimes, this is valid. Ensure this matches existing usage in the JS runtime.🧰 Tools
🪛 Biome (1.9.4)
[error] 40-40: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 44-44: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
146-159
: AllowingFunction
forexceptionExpected
is correct.Per your prior clarifications, you need to accept any function-like value. This is intentional despite some linter warnings.
🧰 Tools
🪛 Biome (1.9.4)
[error] 147-147: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 154-154: void is confusing inside a union type.
Unsafe fix: Use undefined instead.
(lint/suspicious/noConfusingVoidType)
[error] 149-149: Don't use 'Function' as a type.
Prefer explicitly define the function shape. This type accepts any function-like value, which can be a common source of bugs.
(lint/complexity/noBannedTypes)
179-179
: Trailing comma in rest parameter is acceptable in.d.ts
files.TypeScript declaration files permit trailing commas in certain syntax contexts, so there's no strict need to remove it.
🧰 Tools
🪛 Biome (1.9.4)
[error] 179-179: rest elements may not have trailing commas
(parse)
Normally I'd just push this commit up and publish it, but since
@types/tape
already exists, I thought this was worth a PR so others can double check me.