-
-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
more type safe dual signature, closes #2967 #3068
base: next-minor
Are you sure you want to change the base?
more type safe dual signature, closes #2967 #3068
Conversation
🦋 Changeset detectedLatest commit: fb2b42f The changes in this PR will be included in the next version bump. This PR includes changesets to release 30 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
// Note: `Schema.All extends S ? "you can't...` is used to prevent the case where `optional` is implicitly applied. | ||
// For example: `S.String.pipe(S.optional)` would result in `S.String` being inferred as `Schema.All`, | ||
// which is not the intended behavior. This is mostly an aesthetic consideration, so if it causes issues, we can remove it. | ||
return new PropertySignatureWithFromImpl(optionalPropertySignatureAST(from, options), from) | ||
}) | ||
})) as unknown as typeof optional |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure why this is needed, but I had to put it here to make it work. Remember the dual
application before was inferred as (...args: any[]) => any
so this stuff is expected on complex cases, still, should be doable without casting. Probably the user facing error case is giving some problems in using such types within the implementation code. Not sure how you all want to deal with this, so I left it here.
08a7781
to
f23c454
Compare
49507f4
to
2b9b343
Compare
f23c454
to
a542b00
Compare
2b9b343
to
689fed9
Compare
a542b00
to
4443e60
Compare
689fed9
to
a853831
Compare
4443e60
to
24e789a
Compare
a853831
to
30b53d0
Compare
24e789a
to
4088cbc
Compare
30b53d0
to
1853e36
Compare
4088cbc
to
b49da35
Compare
1853e36
to
ad2f1cb
Compare
Imho seems to be over complexifying usage, also it would be a breaking change that potentially breaks user code, not sure about it |
b49da35
to
b93b4d5
Compare
ad2f1cb
to
dba3fc5
Compare
Usage should be the same in the "common case" scenario. There are a couple of instances where it can't infer automatically the whole type you'd like your dual signature to be, and require you to type the It's true some user code could be breaking due to this change, at least at the type level, since this PR is all about types, even if it's just about reordering types so to put generics in place. But it should help spot places where inference would put you in a possibly bad situation runtime wise, due to |
b93b4d5
to
6589289
Compare
dba3fc5
to
8339df3
Compare
6589289
to
0ce7594
Compare
8339df3
to
6d9863c
Compare
0ce7594
to
4ea9615
Compare
6d9863c
to
d3826a8
Compare
dbe532e
to
1179383
Compare
500bd5b
to
9570253
Compare
1179383
to
89f105c
Compare
9570253
to
7bf5f21
Compare
89f105c
to
b304c5c
Compare
7bf5f21
to
12acea2
Compare
b304c5c
to
dd4c6fe
Compare
12acea2
to
eb524c5
Compare
dd4c6fe
to
d6c4889
Compare
eb524c5
to
234fe21
Compare
d6c4889
to
af13d8c
Compare
234fe21
to
7e2189a
Compare
af13d8c
to
c730f99
Compare
a974f1a
to
36f92ae
Compare
9a9d999
to
a8302d7
Compare
36f92ae
to
7efb335
Compare
a8302d7
to
6c77633
Compare
7efb335
to
f933411
Compare
This would be a major change, the changeset will need adjusting.
|
f933411
to
421be0f
Compare
2b4fb20
to
338128e
Compare
421be0f
to
be75135
Compare
338128e
to
e88f4a6
Compare
be75135
to
93ee35a
Compare
e88f4a6
to
b1213de
Compare
93ee35a
to
bc0c90d
Compare
b1213de
to
8ab2b2c
Compare
bc0c90d
to
fb2b42f
Compare
Type
Description
Ad discussed in #2967, the
dual
type signature could be improved to avoid inferring an(...args: any[]) => any
function type, which is assignable to every function signature you define for your dual api, and instead be precise over the implementation signature used. Of course the rest of the type signature would still be unsafe, but that's unavoidable.This should help prevent errors when the type signature of the implementation used for the
dual
api is different to the one used as the final signature of such dual api.NOTICE:
There are a couple of tests failing, regarding the schema package, which should not be related to this change. In fact, if you run the tests on the main this pr is based on, those tests keep failing.
This PR should be type level only. I added dtslint tests for the dual signature type checks I did in the first place that brought this change to exist. This should help to assert those cases are preserved in the future.
Related
dual
signature (prevent type errors/issues) #2967