Proposal: Idiomatic dependency access via this.method() (Memoized)

[Lucifier129]

Is your feature request related to a problem? Please describe.
Currently, accessing sibling tasks requires the specific this.$.key syntax. While functional, this "magic" $ property feels a bit non-standard and less intuitive than calling a method directly on the context.

Describe the solution you'd like
I propose optimizing the API to support direct method calls (e.g., await this.user()) to access dependencies.

Under the hood, these methods should be memoized. This ensures that even if this.user() is called multiple times (by the main runner or other dependent tasks), the underlying fetchUser logic is executed only once, and the same Promise is shared.

Example

Current syntax:

const { user, config, profile } = await all({
  async user() { return fetchUser() },
  async config() { return fetchConfig() },
  async profile() {
    // Requires .$ to access the task
    return fetchProfile((await this.$.user).id)
  }
})

Proposed syntax (More idiomatic):

const { user, config, profile } = await all({
  async user() { return fetchUser() },
  async config() { return fetchConfig() },
  async profile() {
    // Direct method call, automatically memoized
    const user = await this.user()     
    return fetchProfile(user.id)
  },
})

Proof of Concept
I have implemented a prototype demonstrating that this is achievable with perfect TypeScript inference (using ThisType without circular reference issues) and correct runtime behavior.

Demo: TypeScript Playground

This approach makes the code look more like standard class methods or closure patterns, improving readability and developer experience (DX).

[shuding]

I have thought about this when designing the API, but I think it changes the standard JS behavior (adds caching). Downside being:

• it might confuse people (that are unfamiliar with better-all) who are reading the code written by others
• the inner tasks object and methods can still work outside of all(), IMO an explicit error is better

Because of these reasons I went with $.

Gonna reconsider this idea, thanks!