-
Notifications
You must be signed in to change notification settings - Fork 10
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
TypeScript types #127
Comments
The magic to make it work is a bit opaque to me, but the results look good from experimenting. The |
@bakkot the types seem solid to me, I appreciate that there are useful affordances, e.g., having typing for arrays, having the array default to empty if @bakkot could we publish the types to both to |
There’s no easy way in DT for one package to reference the types for another, so the best approach i think is to duplicate them in both DT packages. |
@bcoe Since you control That said, it looks like types for 18.0.0 are still WIP, so I'm probably not going to submit these for |
I find it vastly superior for types to be in DT instead of the package directly, since it avoids conflating the semver of the implementation with that of the types. |
My comments are at a non-expert level. To keep the version numbers sane and allow As for whether to include in package, a comment each way! I'm not concerned about the conflation of types and code by publishing within package. I consider the types part of the package. However, the TypeScript publishing guidance, https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html#handbook-content says:
|
Nice work @bakkot!! I copied your TS Playground and included some light suggestions, specifically:
Additionally, I added a question on the first usage example where: The |
@aaronccasanova Neat! Comments: Re: "Shouldn't Uhh I guess you're right. I assumed that Your changes have broken some of the types. Specifically, |
Yeah, we don't traverse the
I'm seeing the correct types.
We can confidently infer |
That's because you're looking at a variable which is explicitly annotated with that type. Look at the type for
The hole is, knowing that it is definitely a boolean and is not known to be |
For |
Welp, I totally understand the rationale for I tested every permutation and it's very robust 👏 Here is an updated prototype reverting the
As mentioned above, these are light suggestions so feel free to dismiss 🙂 |
Nice, LGTM. |
There is not currently any TSDoc, or indeed JSDoc, for offering guidance beyond the types? (Edit: we wrote JSDoc for the internal routines, but not the exported routine!) For example in Visual Studio Code, where I think the documentation is coming via autodownloaded TypeScript definition files, I see rich assistance for Whereas currently for |
@shadowspawn Good catch, updated with the description from the readme (slightly wordsmith'd for this context):
|
Took another pass and caught two more edge cases:
const results = parseArgs()
const results = parseArgs({})
type ActualResults = {
values: { [longOption: string]: string | boolean | string[] | boolean[] | undefined }
positionals: string[];
}
type ExpectedResults = {
values: {}
positionals: [];
}
// Dynamic config
const config: Config = {
strict: false,
options: { foo: { type: 'string', multiple: true } }
}
const {values} = parseArgs(config)
type ActualValues = {
[longOption: string]: string | boolean | string[] | boolean[] | undefined
}
type ExpectValues = {
[longOption: string]: string | boolean | (string | boolean)[] | undefined
} |
I addressed the above edge cases and added a TON of tests to this playground. Note: This version goes above and beyond to establish robustness between the inference utilties and the test cases (at the cost of readbility). |
Nice! Re: tests, one minor nit: I find it hard to read when there's non-local aliases for the actual results. E.g. Expect<IsEqual<ParseArgs<{ strict: false }>['positionals'], ParsePositionals>> vs Expect<IsEqual<ParseArgs<{ strict: false }>['positionals'], string[]>> or type ExpectedValues = {
foo: ParseResultsValue<string>;
bar: ParseResultsValueMultiple<boolean>;
baz: ParseResultsValueMultipleUnknown<boolean>;
} vs type ExpectedValues = {
foo: string | undefined;
bar: boolean[] | undefined;
baz: boolean[] | boolean | undefined;
} |
Totally! This hit to readability also occurs in the usage... Perhaps it's best to scrap the Here is an update removing the extraneous Note: If folks want to test these types locally simply copy/paste the entire playground into an {
"compilerOptions": {
"strict": true,
"allowJs": true,
"checkJs": true
}
} |
The visible type names might need to be more qualified to disambiguate when used in For example, currently have:
(Noticed when testing using copy-paste instructions from above, thanks.) |
@bakkot Great job! It looks like v18 of |
@mrazauskas I'm waiting on #129 / nodejs/node#43459 to land so we can do the types all at once. But if that stalls much longer I'll open a PR to DefinitelyTyped, yeah. |
OK, node PR landed. Types need to be updated to recognize the optional boolean in the config and to support the new type Token =
| { kind: 'option', index: number, name: string, rawName: string, value: string | undefined, inlineValue: boolean | undefined }
| { kind: 'positional', index: number, value: string }
| { kind: 'option-terminator', index: number }
type Tokens = Token[] It's actually possible to do way better than that for option tokens if the |
Opened DefinitelyTyped/DefinitelyTyped#61512 with the types roughly as discussed here (except with good types for |
A whole lot of accurate typing assistance, thanks @aaronccasanova and @bakkot . |
A PR has been opened to copy these for Nothing for node 16 yet. |
The new Edit: simple type for |
I have a prototype implementation of types for this package, with some type-level shenanigans so that you get exact types on the result as long as you pass the config directly to parseArgs. E.g.:
Any feedback before I submit them upstream? You can play around with the types in the playground linked, no need to install anything.
The text was updated successfully, but these errors were encountered: