Skip to content

[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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

[New] add types #603

wants to merge 1 commit into from

Conversation

ljharb
Copy link
Collaborator

@ljharb ljharb commented Mar 2, 2024

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.

@Raynos
Copy link
Collaborator

Raynos commented Mar 4, 2024

Are these hand written or generated from JSDoc ? It's unclear to me. Either way looks reasonable to me.

@ljharb
Copy link
Collaborator Author

ljharb commented Mar 4, 2024

Hand-written.

This comment was marked as outdated.

coderabbitai[bot]

This comment was marked as outdated.

@ljharb ljharb force-pushed the tsc branch 2 times, most recently from 54b4f2d to decd5d2 Compare March 8, 2024 23:59
coderabbitai[bot]

This comment was marked as outdated.

Copy link
Contributor

@JoshuaKGoldberg JoshuaKGoldberg left a 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.

@ljharb
Copy link
Collaborator Author

ljharb commented Mar 11, 2024

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.

coderabbitai[bot]

This comment was marked as outdated.

coderabbitai[bot]

This comment was marked as outdated.

coderabbitai[bot]

This comment was marked as outdated.

coderabbitai[bot]

This comment was marked as outdated.

coderabbitai[bot]

This comment was marked as outdated.

coderabbitai[bot]

This comment was marked as outdated.

@JoshuaKGoldberg
Copy link
Contributor

Oop, sorry for taking so long - I'd added this tab on my phone and forgot about it 😅. Looking now!

it down to 4 errors

On the latest commit I get no errors. So, nicely done! 😄

Copy link
Contributor

@JoshuaKGoldberg JoshuaKGoldberg left a 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! 👏

Copy link
Contributor

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.

Copy link
Collaborator Author

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?

Copy link
Contributor

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 }} */
Copy link
Contributor

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?

Copy link
Collaborator Author

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
Comment on lines 935 to 932
// TS TODO: `caught.error` and `expected` should both be `object` here
passed = every(keys, /** @type {(key: PropertyKey) => boolean} */ function (key) {
Copy link
Contributor

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.

Copy link
Collaborator Author

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

Copy link
Contributor

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-errors later.

@ljharb ljharb force-pushed the master branch 3 times, most recently from c16dde3 to 2ad86d4 Compare June 16, 2024 06:22
@ljharb ljharb force-pushed the tsc branch 2 times, most recently from 92aa51c to e80d128 Compare August 22, 2024 05:52
@ljharb ljharb changed the title add types [New] add types Aug 22, 2024
coderabbitai[bot]

This comment was marked as outdated.

@codecov-commenter
Copy link

codecov-commenter commented Nov 27, 2024

Codecov Report

Attention: Patch coverage is 91.66667% with 5 lines in your changes missing coverage. Please review.

Project coverage is 96.15%. Comparing base (ecfb546) to head (c75669b).
Report is 24 commits behind head on master.

Files with missing lines Patch % Lines
lib/test.js 88.88% 3 Missing ⚠️
lib/default_stream.js 50.00% 2 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

coderabbitai[bot]

This comment was marked as outdated.

coderabbitai[bot]

This comment was marked as outdated.

@ljharb
Copy link
Collaborator Author

ljharb commented Dec 3, 2024

@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?

coderabbitai[bot]

This comment was marked as outdated.

@andrewbranch
Copy link

@ljharb can you point me to the failure message in CI?

@ljharb
Copy link
Collaborator Author

ljharb commented Dec 3, 2024

coderabbitai[bot]

This comment was marked as outdated.

coderabbitai[bot]

This comment was marked as outdated.

coderabbitai[bot]

This comment was marked as outdated.

coderabbitai[bot]

This comment was marked as outdated.

coderabbitai[bot]

This comment was marked as outdated.

coderabbitai[bot]

This comment was marked as outdated.

Copy link

@coderabbitai coderabbitai bot left a 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 comment

The 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 properties

While Record<PropertyKey, unknown> works, you might consider using a more specific type that describes the expected structure of the object, including the foo property and the inspect method.

-/** @type {Record<PropertyKey, unknown>} */
+/** @type {{ foo: unknown, inspect(): string} & Record<PropertyKey, unknown>} */

245-246: Consider a more specific type for the 'val' variable

Using unknown is safer than any, but since this variable will only store values set to the setter 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 in getTestArgs.

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

📥 Commits

Reviewing files that changed from the base of the PR and between 035877d and c75669b.

⛔ 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 errors

The 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 definitions

These 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 descriptors

The type assertions for property descriptors ensure type safety when accessing get and set 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 between test and Harness.

The @ts-expect-error comment indicates a type compatibility issue between the test function and the Harness 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 like private.


22-27: Explicit this 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 and type 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 of void in the this 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 using undefined.

🧰 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: Retaining void | Test for the this 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: Allowing Function for exceptionExpected 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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants