Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
types(ses): move comments where typedoc can see them (#2205)
closes: #XXXX refs: #XXXX ## Description Before this PR, there was a lot of redundancy between `ses/src/error/types.js` and `ses/types.d.ts` in typing the `ses/src/error/assert.js` module. This cased several problems: - `yarn docs` was picking up only the doc-comments in the `ses/types.d.ts` file, dropping all the useful doc-comments in the `ses/src/error/types.js` file. - redundant expression of the same meaning in different syntaxes is a horrible maintenance burden. They will get out of sync. (This happened to me at first in a recent PR when I added the `sanitize` option.) - The types as exported by the `ses/src/error/types.js` are ambient, which we're trying to reduce and eventually eliminate. The types as exported by `ses/types.d.ts` are not ambient, requiring them to be explicitly imported. Which is finally pleasant with `@import`! - By importing types with `@import` rather than `@typedef {import('...). ...} ...`, the documentation attached to the types is visible in the IDE (at least vscode) and more usage locations. This PR should be a pure refactoring from a runtime semantics POV. No behavior of any code should be any different. All the changes are only to static information: types and doc-comments. ### Security Considerations As mentioned above, redundant expression of the same meaning in different syntaxes ... will get out of sync. This makes code more confusing to review reliably, so this PR helps security. ### Scaling Considerations none ### Documentation Considerations Most of the point! After this PR, `yarn docs` produces much better documentation for the types related to the assert.js module. It is thus also an attempt to get one's feet wet at making this kind of improvement. However, even after this PR, the output of `yarn docs` still leaves plenty of room for further improvement ;) ### Testing Considerations Probably none. Conceivably more type tests could be relevant, but if so it is not apparent to me. ### Compatibility Considerations Because this PR (allegedly) changes no runtime behavior, it cannot cause any incompat runtime behavior. However, client code is also a client of the exported types. Changing types from ambient to non-ambient risks breaking whether old clients continue to pass static type checking. Which brings us back to the oft-repeated question for reviewers: ***Do I need to mark this PR with a `!`?*** ### Upgrade Considerations none. - [ ] Includes `*BREAKING*:` in the commit message with migration instructions for any breaking change. - [ ] Updates `NEWS.md` for user-facing changes.
- Loading branch information