Open konstantinepapakonstantinou opened 2 years ago
Made a PR for this: https://github.com/evaera/roblox-lua-promise/pull/84
It feels like Luau doesn't have the features we need to type Promises correctly yet.
You can either infer types from the constructor, or declare the types in a typedef and have them be completely unchecked. (You also won't get the metatable as part of the type if you do the typedef route as well)
The inferred type of the constructor will contain private fields, and doesn't seem like it can support generics. We ideally want the Promise type to be Promise<T..., E...>
You'd start it off by saying export type Promise<T> = typeof(Promise.new(function end))
... and then there's nowhere to put the type variable, because Luau doesn't support passing generic types explicitly
Both of these options seem like non-starters to me. Having private fields and no types for the inner resolved/rejected values in the Promise type because we can't specify generic arguments is not useful.
On the other hand, using a large type definition is separated from the code and is completely unchecked.
Here's a small example of that:
type Promise = {
andThen: (Promise, (...any) -> Promise | any) -> Promise
}
local Promise = {}
Promise.__index = Promise
-- Type Error: (11,2) Type '{ @metatable Promise, { } }' could not be converted into 'Promise'
function Promise.new(): Promise
return setmetatable({}, Promise)
end
function Promise:andThen(func: (...any) -> Promise | any): Promise
end
This doesn't type check. The only option is to cast the return value of Promise.new
into the Promise
type manually, which is not sound.
I don't think Luau type checking quite has the tools required to type the Promise library yet.
I completely agree that hacky solutions are no good here. I don't know if these issues are currently being addressed by the Luau team or not- but it wouldn't hurt to let them know. I don't develop anymore on the platform, but Promises were a really big part of the codebases I worked on and the lack of type checking made things difficult. There's always Roblox-TS, but ideally we wouldn't need that abstraction.
Yea, you currently run into a few Luau limitations but can still get some pretty good checking for the first level of a Promise chain that has found some cool bugs for me. Here's the way I've made the best out of the current Luau type checking and syntax:
-- TODO Luau: workaround for Luau recursive type used with different parameters error. delete this copy once that feature is added.
export type _Thenable<R> = {
andThen: <U>(
self: _Thenable<R>,
onFulfill: (R) -> () | U,
onReject: (error: any) -> () | U
) -> (),
}
export type Thenable<R> = {
andThen: <U>(
self: Thenable<R>,
onFulfill: (R) -> () | _Thenable<U> | U,
onReject: (error: any) -> () | _Thenable<U> | U
-- TODO Luau: need union type packs to parse () | Thenable<U>
) -> nil | _Thenable<U>,
}
Looks like Luau supports type packs now: https://luau-lang.org/typecheck#type-packs
Hi! It's been a while since this issue was opened. Was it considered revisiting whether typing the library in Luau is doable yet?
It should be possible now with the improvements made to luau in the past year, assuming the new type solver is on by default.
Would like to have an official update for this too, not having luau type has been really annoying to use
The new type solver isn't enabled in Roblox, so this isn't possible yet.
The new type solver isn't enabled in Roblox, so this isn't possible yet.
is VS CODE affected by this not being enabled by Roblox?
The new type solver isn't enabled in Roblox, so this isn't possible yet.
is VS CODE affected by this not being enabled by Roblox?
By VS CODE I'm assuming you mean Luau LSP.
I believe that you can manipulate Luau-specific FFlags to enable or disable certain features, such as the new type solver. I'm not exactly sure what the flag is, but I'm fairly certain it's a work in progress and not officially released yet.
If someone in the community is able to create types and submit a PR, I'd be happy to review. I'm afraid I don't have the time to work on this myself.
Super low-priority issue that serves as merely an inconvenience- I've completely transitioned into using strict typings for all of my projects (sadly, I haven't had the opportunity to take up TypeScript just yet). It would be super helpful if we could have a few types implemented for Promises (namely, a Promise type) so I won't have to use "any" everywhere in my code.