Thanks for the PR, @dak2!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint.

✅ Deploy Preview for typescript-eslint ready!

Name	Link
🔨 Latest commit	1567418
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/66cb1e7a50358f00088821fe
😎 Deploy Preview	https://deploy-preview-9632--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 99 (no change from production) Accessibility: 100 (no change from production) Best Practices: 92 (no change from production) SEO: 90 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

To edit notification comments on pull requests, go to your Netlify site configuration.

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 1567418. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

Sent with 💌 from NxCloud.

@bradzacher

Thanks! Looks like I was mistaken, I fixed it to use Expression.

I don't know why CI failed. Perhaps there is an error when running yarn, but I can't reproduce it locally.

Here's the relevant log in CI (I believe):

  ➤ YN0000: │ @typescript-eslint/typescript-eslint@workspace:. STDOUT > nx run eslint-plugin:build
  Error: ➤ YN0000: │ @typescript-eslint/typescript-eslint@workspace:. STDOUT src/rules/no-throw-literal.ts(93,28): error TS2345: Argument of type 'TSAsExpression | Statement | null' is not assignable to parameter of type 'Node'.
  ➤ YN0000: │ @typescript-eslint/typescript-eslint@workspace:. STDOUT   Type 'null' is not assignable to type 'Node'.
  Error: ➤ YN0000: │ @typescript-eslint/typescript-eslint@workspace:. STDOUT src/rules/only-throw-error.ts(92,28): error TS2345: Argument of type 'TSAsExpression | Statement | null' is not assignable to parameter of type 'Node'.

cc @JamesHenry - I think that NX is improperly caching the build here.
The AST spec has changed so that the property is just argument: Expression, yet the compilation step from ast-spec src to types/src/generated/ast-spec.ts is reusing the old output.

@bradzacher @Josh-Cena
Thanks for your help!
I think rebuild without cache before run yarn install --immutable --inline-builds in GitHub Actions.
Any concerns about this approach? Or is there another effective way?

I've tried deleting cache, tried prebuild, but it doesn't seem to work.

@dak2 You don't need to worry about CI failures. As long as your code is valid, the burden of fixing the CI is on the team.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.03%. Comparing base (90cebbb) to head (1567418).
Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main    #9632      +/-   ##
==========================================
- Coverage   88.03%   88.03%   -0.01%     
==========================================
  Files         407      407              
  Lines       13942    13941       -1     
  Branches     4072     4071       -1     
==========================================
- Hits        12274    12273       -1     
  Misses       1355     1355              
  Partials      313      313              

@bradzacher Sorry I missed your comment here, let's double check and make sure we have the cache inputs set up correctly for this case

The reason for the failure was that we were telling nx to exclude test files from build cache inputs. spec.ts is a super common naming convention for test files and so that's why it was included in the pattern, but our more unique "ast spec" convention was therefore caught in the crossfire and changes to ast spec.ts files were appropriately (based on our config) not causing the build cache to be invalidated.

In our repo we are actually consistent with our usage of test.ts for test files, so the solution here is to stop classing spec.ts as test files in the build inputs (and I did some minor consistency cleanup for old references to spec in the test context)

Thanks again @dak2!