feat(allow-scripts): generate & ship typescript declarations #675
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
|
This is the same as #617, which was closed due to Reasons. |
boneskull
force-pushed
the
boneskull/ts
branch
from
98b76b2
to
694745a
Compare
This was referenced Aug 23, 2023
legobeat
reviewed
Aug 24, 2023
boneskull
force-pushed
the
boneskull/ts
branch
3 times, most recently
from
358cc18
to
5b8795c
Compare
boneskull
force-pushed
the
boneskull/ts
branch
from
5b8795c
to
5306be9
Compare
This was referenced Sep 1, 2023
Merged
boneskull
force-pushed
the
boneskull/ts
branch
6 times, most recently
from
a44e35c
to
7abf2ef
Compare
boneskull
force-pushed
the
boneskull/ts
branch
3 times, most recently
from
7f857a0
to
f9f4cd7
Compare
This adds `.d.ts` generation to `@lavamoat/allow-scripts`. - Many type defs added to `src/types` for those modules which do not have them (nor are there any published to DefinitelyTyped). In the future, some of these could be submitted to DefinitelyTyped, if we wish. - Upgrade `yargs` - Create reusable TS configuration supporting incremental builds - Declaration files generated at build time and shipped in the `types` folder (which is now in `.gitignore`) - Created `.depcheckrc` - Added, updated, removed and/or fixed many docstring types Note: the uncommon `skipLibCheck = false` setting in this module's `tsconfig.json` enables typechecking of the `.d.ts` files themselves. These files are not compiled.
boneskull
force-pushed
the
boneskull/ts
branch
from
d4e6af7
to
e461a9f
Compare
leotm
reviewed
Oct 5, 2023
leotm
reviewed
Oct 5, 2023
leotm
reviewed
Oct 5, 2023
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a PoC for creating (and shipping) declaration files for LavaMoat packages.
Right now, I've fully typed the sources (not the tests) of @lavamoat/allow-scripts, which now validates the types in "strict" mode. TypeScript is configured for incremental builds (preferable for monorepos), but only builds one module as a PoC.
To generate types, execute npm run build:types in the @lavamoat/allow-scripts workspace. They will be output into packages/allow-scripts/types (which is not under VCS).
I added available type declarations (from DefinitelyTyped), but I had to write a handful of my own for external modules. These do not appear to be re-exported. AFAICT (but I haven't tested it!) there aren't any type declarations that are needed as production dependencies (in @lavamoat/allow-scripts, anyway).
I took some liberties tweaking existing types (narrowing where appropriate, separating @typedefs so that descriptions would be picked up, etc.). I'd prefer if we used the T[] syntax for arrays instead of Array, but that's just my personal preference and I stuck to the current convention.
I note that these .d.ts files I created have semicolons which is a byproduct of my IDE's default formatting. If we intend to keep any of these around, I'd recommend pulling in @typescript-eslint/plugin and its ilk.