Automated npm publish, an Actions bot to enforce PR names, and the like. I've been wanting to set this up in a repo for ages!

Bug Report Checklist

• I have tried restarting my IDE and the issue persists.
• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

Splitting out from microsoft/DefinitelyTyped-tools#858 (comment): @definitelytyped/expect internally "normalizes" commented types by creating a virtual source file with a type annotation, then stringifying the type annotation. https://github.com/microsoft/DefinitelyTyped-tools/blob/3d6c2ffd0b38eac222e03156c3d62d6020b2b94b/packages/eslint-plugin/src/rules/expect.ts#L492

That feature is particularly useful for when you have multiple TS versions (#107). It's also generally nice to be a little less nitpicky for users (see also: #18). Let's take that feature in here!

Additional Info

No response

Overview

Spinning out from @danvk's #67 (comment):

Suggest adding a note in README.md (or some other doc) about how to update the docs, run the tests, publish the package, etc.

Agreed. I've been working on getting a nice comprehensive starter for TypeScript projects in https://github.com/JoshuaKGoldberg/template-typescript-node-package. Filing this issue to bring the features such as automatic semver publishing & comprehensive CI checks here.

🐛 Bug Report

• eslint-plugin-expect-type version: 0.2.0
• ESLint version: 8.23.0
• Node version: 16.17.0

Actual Behavior

Bumping projects to TS v4.8 makes the plugin error

/Users/cedric/Code/ninjasquad/examples/node_modules/typescript/lib/typescript.js:167586
                fileExists: function (fileName) { return host.fileExists(fileName); },
                                                              ^

TypeError: Error while loading rule 'expect-type/expect': host.fileExists is not a function

Expected Behavior

It would be awesome to support the latest TS version.

Reproduction

It looks like bumping TS in the package.json of the plugin repo, and running npm test reproduces the issue:

 FAIL  tests/rules/twoslash.test.ts
  ● Test suite failed to run

    src/rules/expect.ts:507:3 - error TS2739: Type '{ getCompilationSettings: () => CompilerOptions; getCurrentDirectory: () => string; getDefaultLibFileName: () => string; getScriptFileNames: () => string[]; getScriptSnapshot: (name: string) => IScriptSnapshot; getScriptVersion: () => string; }' is missing the following properties from type 'LanguageServiceHost': readFile, fileExists

    507   return {
          ~~~~~~~~
    508     getCompilationSettings: () => program.getCompilerOptions(),
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ...
    513     getScriptVersion: () => '1',
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    514   };
        ~~~~

🚀 Feature Request

#47 adds an autofixer for just twoslash rules. I love it.

@danvk mentioned there the autofixer could be added for other rules as well.

Bug Report Checklist

• I have tried restarting my IDE and the issue persists.
• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

This plugin is not working when using bun or yarn workspaces and importing a module from another package in the workspace that contains declaration files. I originally created a bug ticket for typescript-eslint and they were able to rule out any issues on their end. I created a repo to reproduce the issue.

Additional Info

No response

🖤

Bug Report Checklist

• I have tried restarting my IDE and the issue persists.
• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

Splitting out from microsoft/DefinitelyTyped-tools#858 (comment): @definitelytyped/expect allows comments to specify multiple allowed type candidates with ||. https://github.com/microsoft/DefinitelyTyped-tools/blob/42484ff245f6f18018de729f12c9a28436daa08a/packages/eslint-plugin/src/rules/expect.ts#L466

That's useful in particular when testing across TS versions (#107). Let's bring the feature in here!

Additional Info

No response

Overview

See this Twitter thread: https://twitter.com/JoshuaKGoldberg/status/1514631630006149120 / https://twitter.com/danvdk/status/1514631780241850370.

This should be noted in the docs, with links to packages like expect-type.

Overview

I noticed in #44 that

Change Proposal

It should be possible to use the RuleTester class exported by typescript-eslint instead now per https://typescript-eslint.io/docs/development/custom-rules#testing.

Marking this cleanup issue as accepting PRs if anybody would like to replace some or all of this repo's custom testing code with the standard RuleTester.

🐛 Bug Report

• eslint-plugin-expect-type version: 0.2.2
• ESLint version: 8.36.0
• Node version: 16.3.0

Actual Behavior

Full reduced test case here: https://github.com/OliverJAsh/eslint-plugin-expect-type-issue

Contents inlined below.

package.json:

{
  "dependencies": {
    "@typescript-eslint/parser": "^5.55.0",
    "eslint": "^8.36.0",
    "eslint-plugin-expect-type": "^0.2.2",
    "typescript": "^5.0.2"
  }
}

tsconfig.json:

{
  "compilerOptions": {
    "strict": true
  }
}

.eslintrc.js:

const path = require("path");

module.exports = {
  parser: "@typescript-eslint/parser",
  parserOptions: {
    project: path.join(__dirname, "./tsconfig.json"),
  },
  plugins: ["eslint-plugin-expect-type"],
  rules: {
    "expect-type/expect": "error",
  },
};

source.ts:

export type Compact<A> = A extends Function ? A : { [K in keyof A]: A[K] } & {};

test.ts:

import { Compact } from "./source";

declare const any: any;

const x: Compact<Record<"a" | "b", number> | Record<"a" | "c", number>> = any;

// ❌ Error:
//  Expected type to be: { a: number; b: number; } | { a: number; c: number; }, got: Compact<Record<"a" | "b", number> | Record<"a" | "c", number>>
// $ExpectType { a: number; b: number; } | { a: number; c: number; }
type Test1 = typeof x;

// ✅ No error
type Test2 = typeof x;
//   ^? type Test2 = {
//          a: number;
//          b: number;
//      } | {
//          a: number;
//          c: number;
//      }

• $ExpectType expects: Compact<Record<"a" | "b", number> | Record<"a" | "c", number>>
• Twoslash expects:

     type Test2 = {
      a: number;
      b: number;
  } | {
      a: number;
      c: number;
  }

I believe the reason for this difference is because Twoslash and $ExpectType use different mechanisms to generate the "actual" value:

• Twoslash: languageService.getQuickInfoAtPosition
• $ExpectType: checker.typeToString

This particular issue started after we upgraded to TypeScript 5. Prior to this, $ExpectType had the same behavior as Twoslash in this particular example. I'm not sure why this has changed.

Expected Behavior

Twoslash queries and $ExpectType should behave the same.

Reproduction

https://github.com/OliverJAsh/eslint-plugin-expect-type-issue

🚀 Feature Request

See #36:

Having unformatted snap makes it really hard to review changes.

For example, if you refactor your code and change just 1 type, in git diff, it looks like the entire file is changed. It's really hard to read and understand if the diff is valid or not.

Examples are generated from the local patch for https://github.com/BatuhanW/haf project.

Existing Behavior

Change Proposal

Since I last redid this project's README.md, https://vitest.dev/guide/testing-types.html came out! I think it should be mentioned in the list of other type testers.

Overview

Per #54 (comment): we should verify that a .d.ts file still can report expect-type failures.

Blocked on typescript-eslint/typescript-eslint#1891.

types should be compared using the compiler API or something. using a string comparison causes many problems when you aren't sure exactly how the compiler will resolve a type.

some examples:

 Expected type to be: 1|2, got: 1 | 2 

type Foo = { foo: number; bar: number }

//fails: Expected type to be: {foo: number; bar: number}, got: Foo
const foo = {} as Foo // $ExpectType {foo: number; bar: number}

since typescript is structurally typed, it doesn't make sense for it to behave that way.

Bug Report Checklist

• I have tried restarting my IDE and the issue persists.
• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

Following #69: src/rules/expect.ts is quite large. Regardless of whether it gets split up into smaller rules, I'd like to refactor it to be easier to work with.

Additional Info

No response

Overview

Per #54 (review): nothing checks now that lines of code are tested. Lint rule plugins typically have very high coverage; our ~80-85% metric is actually unusually low.

A lot of repos use Codecov -- including typescript-eslint. Are there alternatives? Should we just go with Codecov?

As of #54 being merged, the coverage report on main is:

=============================== Coverage summary ===============================
Statements   : 82.78% ( 226/273 )
Branches     : 75.7% ( 81/107 )
Functions    : 94.44% ( 34/36 )
Lines        : 82.19% ( 217/264 )
================================================================================

GitHub md docs to help keep formalize templates of issues and pull requests. 💖

Overview

https://typescript-eslint.io/docs/development/custom-rules#testing describes how to use RuleTester. Let's use that instead of rule as unknown as ....

🚀 Feature Request

https://github.com/bmish/eslint-doc-generator allows scaffolding docs for ESLint plugins. Let's use it!

🐛 Bug Report

• eslint-plugin-expect-type version: 0.0.7
• ESLint version: X.X.X
• Node version: X.X.X

Actual Behavior

└─┬ eslint-plugin-expect-type                                                                                    
  └── ✕ unmet peer eslint@"^5.0.0 || ^6.0.0": found 8.11.0

Expected Behavior

Reproduction

Bug Report Checklist

• I have tried restarting my IDE and the issue persists.
• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

Spinning out of #113: that PR included no test changes because the impacted lines weren't previously covered by tests at all. Accepting PRs to add tests in!

Additional Info

Note that type snapshots impact the file system, so it might be nontrivial to set up testing for them. My hunch is to try using Vitest mocking.

Ever since #7, I think?

Overview

What version range of TypeScript should this plugin support?

Actual Behavior

Apparently it goes back to 2.0:

Expected Behavior

I'd propose going along with https://github.com/DefinitelyTyped/DefinitelyTyped/#support-window: versions of TypeScript less than 2 years old.

Let's:

• Explicitly document this in the README.md
• Remove that TypeScript support shim

Bug Report Checklist

• I have tried restarting my IDE and the issue persists.
• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

Porting over from microsoft/DefinitelyTyped-tools#858: @definitelytyped/expect has the ability to receive a versionsToTest option. That option contains an array of TS versions with paths to the node_modules. The plugin then runs roughly:

for (const version of versionsToTest) {
  const ts = require(version.path) as TSModule;
  const program = getProgram(tsconfigPath, ts, version.versionName, parserServices.program);

Let's port that feature over to eslint-plugin-expect-type. I think it can exist roughly as-is. Maybe some bikeshedding on the option name?

Additional Info

Edit: This would support react-native-community/discussions-and-proposals#719 (comment) too.

Edit: ...and microsoft/DefinitelyTyped-tools#440

In my TypeScript book, I’m using @ts-expect-error with error messages to point out if there are errors – e.g.:

function func(value: unknown) {
  // @ts-expect-error: Object is of type 'unknown'.
  value.toFixed(2);

  // Type assertion:
  (value as number).toFixed(2); // OK
}

Benefit: Very similar to assert.throws() in that type checking doesn’t fail if everything is as expected.

All examples from my book: https://gist.github.com/rauschma/4d1ee06e47e03545d4c4b31b59700786

🚀 Feature Request

This plugin uses dtslint-style syntax for type assertions ($ExpectError). But twoslash syntax (^?) seems to be getting lots of adoption lately (including on the TypeScript playground) and it could also be a good fit here. It neatly dodges the question of "what exactly am I asserting the type of?" by making it incredibly explicit.

Existing Behavior

const square = (x: number) => x * x;
const four = square(2);  // $ExpectType number

Change Proposal

const square = (x: number) => x * x;
const four = square(2);
//    ^? const four: number

A fix mode to automatically fill these types in (ala the TS playground) would also be rad, but that's for a different feature request.

Bug Report Checklist

• I have tried restarting my IDE and the issue persists.
• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Expected

As originally reported by #14: type snapshots should update if ESLint is run in --fix mode. For a while they were always being updated (unless disableExpectTypeSnapshotFix was enabled).

Actual

As of #113, type snapshots are only updated if process.argv.includes('--fix'). That doesn't account for programmatic usage of ESLint's Node.js API such as from an editor extension.

Additional Info

No response

🐛 Bug Report

• eslint-plugin-expect-type version: 0.2.1
• ESLint version: 8.26.0
• Node version: 18

Actual Behavior

The diff produced on mac/linux is correct, but on Windows the expected diff includes an extraneous line which causes eslint to error:

  13:10  error  Expected type to be: type _response = {
    id: string;
    taskID?: string | undefined;
    paramValues: ParamValues;
    status: RunStatus;
    output: string;
}
, got: type _response = {
    id: string;
    taskID?: string | undefined;
    paramValues: ParamValues;
    status: RunStatus;
    output: string;
}  expect-type/expect

Expected Behavior

The diff should match.

Reproduction

Here's an example CI run that shows the error: https://github.com/airplanedev/js-sdk/actions/runs/3440332462/jobs/5738676594

We ended up disabling this on Windows as a workaround.

🐛 Bug Report

• eslint-plugin-expect-type version: 0.2.1
• ESLint version: 8.27.0
• Node version: 18

Actual Behavior

If code is indented with tabs, this plugin produces "Can not match a node to this assertion" errors.

I've also seen issues with --fix where lines in tab-indented code get duplicated. That appears related, but I don't have a reliable reproduction.

Expected Behavior

Code indented with tabs should work the same as that indented with spaces.

Reproduction

https://github.com/colinking/repros-eslint-plugin-expect-type/tree/main/tabs

Run npm run lint -- --fix to run eslint. Notice the lines that are indented with spaces are validated correctly, but the lines indented with tabs produce the errors.

🐛 Bug Report

• eslint-plugin-expect-type version: 0.1.0
• ESLint version: N/A
• Node version: N/A

Actual Behavior

Right now, any pre-emit diagnostic (so, some classes of compile errors) are emitted in expect.ts. See the addDiagnosticFailure function.

  const diagnostics = ts.getPreEmitDiagnostics(program, sourceFile);

  // ...

  for (const diagnostic of diagnostics) {
    addDiagnosticFailure(diagnostic);
  }

Expected Behavior

There's no need for the tool to do this. I see it as a bug, not a feature.

The addDiagnosticFailure function should be removed.

Reproduction

export const duplicate: number;
export const duplicate: number;

GitHub labels to help keep track of issues and pull requests. 💖

Just noticed a "thanks for originally creating this!" kind of message isn't in the README.md. It should be!

🐛 Bug Report

• eslint-plugin-expect-type version: 0.2.0
• ESLint version: 8.24.0
• Node version: 18.7.0
• TypeScript version: 4.8.4

Actual Behavior

yarn lint

Oops! Something went wrong! :(

ESLint: 8.24.0

TypeError: Error while loading rule 'expect-type/expect': host.fileExists is not a function
Occurred while linting /Users/josh/repos/typescript-static-analysis-hidden-gems/src/linting/types.test.ts
    at Object.fileExists (/Users/josh/repos/typescript-static-analysis-hidden-gems/node_modules/typescript/lib/typescript.js:167620:63)
    at host.fileExists (/Users/josh/repos/typescript-static-analysis-hidden-gems/node_modules/typescript/lib/typescript.js:117500:47)
    at getPackageJsonInfo (/Users/josh/repos/typescript-static-analysis-hidden-gems/node_modules/typescript/lib/typescript.js:44461:37)
    at loadModuleFromSpecificNodeModulesDirectory (/Users/josh/repos/typescript-static-analysis-hidden-gems/node_modules/typescript/lib/typescript.js:45001:27)
    at loadModuleFromImmediateNodeModulesDirectory (/Users/josh/repos/typescript-static-analysis-hidden-gems/node_modules/typescript/lib/typescript.js:44982:58)
    at /Users/josh/repos/typescript-static-analysis-hidden-gems/node_modules/typescript/lib/typescript.js:44972:39
    at Object.forEachAncestorDirectory (/Users/josh/repos/typescript-static-analysis-hidden-gems/node_modules/typescript/lib/typescript.js:8370:26)
    at loadModuleFromNearestNodeModulesDirectoryWorker (/Users/josh/repos/typescript-static-analysis-hidden-gems/node_modules/typescript/lib/typescript.js:44966:19)
    at loadModuleFromNearestNodeModulesDirectory (/Users/josh/repos/typescript-static-analysis-hidden-gems/node_modules/typescript/lib/typescript.js:44958:16)
    at tryResolve (/Users/josh/repos/typescript-static-analysis-hidden-gems/node_modules/typescript/lib/typescript.js:44053:34)

Expected Behavior

This should still work in newer versions of TypeScript.

Downgrading to [email protected] fixes the issue.

Reproduction

JoshuaKGoldberg/typescript-static-analysis-hidden-gems@bc57f20

Thanks for the great library!

The issue is, I'm changing one of the test types expecting them to throw an error. Then running eslint without --fix option. It still updates snapshots.

Edit: I found out that explicitly setting "expect-type/expect": ["error", { "disableExpectTypeSnapshotFix": false }] fixes the issue. It only generates snapshots with --fix.

Having no rule at all doesn't prevent snapshots to be generated.

Bug Report Checklist

• I have tried restarting my IDE and the issue persists.
• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

Configuration using legacy eslintrc will be deprecated in ESLint soon. We're going to want to support flat configs!

Additional Info

No response

no error:

const foo = 1 //$ExpectType string

error:

const foo = 1 // $ExpectType string

Bug Report Checklist

• I have tried restarting my IDE and the issue persists.
• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

I have a Customization<From, To> type that calculates what can/must be provided in order to transform a value of type From into a value of type To. This type can conveniently be checked by twoslash checks, e.g.:

const x1: Customization<{}, { x: number }> = {} as any;
//    ^? const x1: {
//           x: number;
//       }
const x2: Customization<{}, { x?: number }> = {} as any;
//    ^? const x2: {
//           x?: number | undefined;
//       }

Unfortunately, when the Customization type is imported from an external dependency then the twoslash checks fail. The type returned in the quick info stays unchanged:

const x1: Customization<{}, { x: number }> = {} as any;
//    ^? const x1: Customization<{}, {
//           x: number;
//       }>
const x2: Customization<{}, { x?: number }> = {} as any;
//    ^? const x2: Customization<{}, {
//           x?: number | undefined;
//       }>

However, when hovering over x1 and x2 in VSCode or IntelliJ, the reduced representation is still shown.
It would be great, if the language service that is used by twoslash checks would be configured in such a way that it returns the same quick info that IDEs show.

Additional Info

Attached you find a GIF that show how the quick info shown by IntelliJ differs from the quick info used by the twoslash check.

🐛 Bug Report

• eslint-plugin-expect-type version: 0.1.0
• ESLint version: N/A
• Node version: N/A

Actual Behavior

This paraphrasing of code in expect.ts explicitly stops this plugin from operating on declaration files:

  if (sourceFile.isDeclarationFile || !/\$Expect(Type|Error)/.test(sourceFile.text)) {
    // ...
    return;
  }

Expected Behavior

Users are going to want to run the assertions inside .d.ts files. It might have been intentional originally, but I see this as a bug.

The sourceFile.isDeclarationFile check should be removed.

Reproduction

// index.d.ts
// $ExpectType number
export const value: string;

(Thanks for sharing this lint rule! ❤️)

Repro

Reduced test case: https://github.com/OliverJAsh/eslint-type-tests-test

1. Run yarn
2. Run eslint index.ts

tsconfig.json:

{
  "compilerOptions": {
    "noUnusedLocals": false,
    "noUnusedParameters": false
  }
}

foo.ts:

export const foo = 1;

index.ts:

import { foo } from './foo';

// $ExpectType 1
type F = typeof foo;

Expected Result

No lint error

Actual Result

$ eslint index.ts

/Users/oliverash/Development/eslint-type-tests-test/index.ts
  53:2  error  TypeScript compile error: 'F' is declared but never used  expect-type/expect

✖ 1 problem (1 error, 0 warnings)

Additional Info

It looks like this happens because typescript-estree enables noUnusedLocals/ noUnusedParameters. Code here: https://github.com/typescript-eslint/typescript-eslint/blob/bf904ec72db57174fec531f61e9427230662553e/packages/typescript-estree/src/create-program/shared.ts#L19-L23

It looks like there is no way to disable these compiler options, even if they are specified as false in the TS config (as I have done in my reduced test case).

In this case I don't want ESLint to error if something is unused. It's sometimes helpful to declare a type/variable which is "unused", so we can hover over the declaration to inspect its type.

Perhaps this lint rule should filter out these TS errors if noUnusedLocals/noUnusedParameters are not enabled by the local project?