Can I work on this? (Of course, I all know that this won't be accepted until the RC is released)

Feel free!

Would be nice to have new @typescript-eslint/no-confusing-void-expression options for typescript 5.2

• ignoreDisposableStackAdopt
• ignoreAsyncDisposableStackAdopt

To allow

AsyncDisposableStack.adopt<void>(value: void, onDisposeAsync: (value: void) => void | PromiseLike<void>): void

Use case

  const dox = async (): Promise<void> => {}
  const undox = async (): Promise<void> => {}
  stack.adopt(
    // eslint-disable-next-line @typescript-eslint/no-confusing-void-expression
    await dox(),
    undox,
  )

@loynoir By passing await dox() - aren't you making the stack adopt undefined?
What's the usecase for having a disposable like this?
It looks like the intention is to call undox during the disposal step.

Based on my reading of the spec - I think you'd be better to use defer instead to register a disposal callback:

{
  using stack = new AsyncDisposableStack();
  await dox();
  stack.defer(undox);
  // ...
  
  // undox is called
}

I don't know if it's too late to change proposal-explicit-resource-management to enforce pair-using.

And stack.adopt is guaranteed pair, but stack.defer is not guaranteed pair.

What do you mean by a "guaranteed pair"?

The idea behind adopt is that you pass a value that later is passed to the cleanup function and cleaned up - eg adopt(createStream(), stream => stream.cleanup())

await dox() ==== undefined - so you're passing a value that can never be disposed - you're really just registering undox as a cleanup function.
Thus I'm not sure I understand how adopt(undefined, cleanup) is any better than defer(cleanup).

so you're passing a value that can never be disposed

?

> var ADS=require('core-js-pure/full/async-disposable-stack/index.js')
[Function: AsyncDisposableStack]
> var stack=new ADS()
AsyncDisposableStack {}
> stack.adopt(undefined,()=>console.log(42))
undefined
> await stack.disposeAsync()
42

Thus I'm not sure I understand how adopt(undefined, cleanup) is any better than defer(cleanup).

• stack.adopt(A(), B) must B

• A() might not follow with stack.defer(B)

await dox()

What I'm saying is that code could be rewritten and it would do the same:

// yours
stack.adopt(await a(), b);

// same as
await a();
stack.adopt(undefined, b);

// same as
await a();
stack.defer(b);

// same as
stack.defer((await a(), b));

I.e. you're just using adopt to visually group things together. You could do the same thing with defer and avoid the unnecessary undefined pass and lint rule violation.

I don't think that this is something we'll look to support.

@bradzacher

Same for machine, not same for human.

await a_long_long_long_init(
 p0_long_long_long(),
 p1_long_long_long(),
 p2_long_long_long(),
)

// oops, no `b`, no err

stack.adopt(
  await a_long_long_long_init(
   p0_long_long_long(),
   p1_long_long_long(),
   p2_long_long_long(),
  )
  
  // oops, no b, must follow with b

But again - there's nothing enforcing you do this. This is just a convention you've created. Your code could also be refactored to be adopt(console.log(), undox) and it would continue to pass type checking and nobody would be any the wiser.

I think I've gathered enough information to say that we won't be looking to have such a feature with the initial release. It doesn't seem like it's going to be a common pattern for the reason provided.

Its too early to tell exactly how people will use the new api and syntax so we're not looking to introduce lint rules about them for now.

The RC is out - so we should look to implementing this soon

I upgraded to 5.2 and my linting started failing with:

DeprecationError: 'originalKeywordKind' has been deprecated since v5.0.0 and can no longer be used. Use 'identifierToKeywordKind(identifier)' instead

Before 5.2, this was a warning:

DeprecationWarning: 'originalKeywordKind' has been deprecated since v5.0.0 and will no longer be usable after v5.2.0. Use 'identifierToKeywordKind(identifier)' instead.

I had a hard time figuring out where these errors were coming from because ESLint would not provide a stack trace, but I'm pretty sure it's coming either from this project or the tsutils dependency that it brings in.

I mention this because I don't see it mentioned in the original issue. Is this something you're aware of/is your responsibility? (Sorry if this is a red herring... I had to do a bunch of guesswork with rg --no-ignore originalKeywordKind-type stuff since ESLint was not forthcoming with a clear stack trace, even with --debug, etc.)

This would be a reasonable place to file that! But:

or the tsutils dependency that it brings in

Make sure you're on the latest version of our tooling. We haven't used tsutils since 6.0. #6428 (now, ts-api-utils)

The only mention of originalKeywordKind I see in this repo is this fallback condition for older versions of TS:

Thanks for the pointers! You saved me a lot of time in chasing this down: ultimately, a caching issue resolved by removing .eslintcache. (I was not previously aware that behavior existed.)

This will be released with our next release

https://typescript-eslint.io/users/releases

Question on this -- during the period when there's a new TS release and this plugin has caught up with it, there does not seem to be any way to resolve yarn dependencies other than pinning back TypeScript, which I do not want to do.

Why can't @typescript-eslint/* express its current version limitations so that yarn obeys them? I.e., why is the typescript dependency specified as "typescript": "*"?

https://typescript-eslint.io/users/dependency-versions#version-warning-logs

For a lot of new TS versions our tooling will "just work" before we have official support - new syntax sometimes will also "just work". It's the rare case that our tooling actively breaks due to a TS release.

So why should we force people to wait for us to explicitly version bump when it's likely things will work fine?

Okay, its just a very annoying situation if you happen to be building a new project in the 5 days when this is being sorted out, and you don't want to see that loud warning every time you run eslint. I ended up hacking yarn.lock to work around it.

I get the reasoning though.

you don't want to see that loud warning every time you run eslint

https://typescript-eslint.io/packages/parser#warnonunsupportedtypescriptversion