-
-
Notifications
You must be signed in to change notification settings - Fork 68
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
Towards v1.0.0 #196
Comments
Thanks for tagging me and thanks for mentioning One of the details I was thinking to add, but didn’t had enough time was primitive type matchers like: |
By the way, integration with Jest wasn’t very good idea. Semi related: |
Many good ideas here 👍
👍
I agree, it should accept globs patterns. I would still prefer (for selfish reasons) it to default to running on the entry point when no input is specified though. But I could be convinced otherwise.
👍
👍
👍
👍
👍
It's a "nice to have", but there's a huge amount of other work that is more important than this.
Also a "nice to have", but the core
👍 |
Agreed, meant to clarify that the
Would you want to set this up, or get in touch with Sam to do so? |
It's not up to me, but I will ask Sam. |
I'm definitely open to moving everything I just checked, the name |
|
👍 |
@SamVerschueren friendly bump :) |
Thanks for the ping :). I totally missed the responses. I now moved |
Quick update, since It was interesting to play with it. I learned a lot, but some limitations were inherited from the architecture of This brought me to TSTyche. It took two years to develop the code. (That is a hobby project, so writing a line or two in the evening was good enough speed.) Repo: https://github.com/tstyche/tstyche Give it a try, please. TSTyche is published as beta to collect feedback. Stable release is coming out in a month or two. PS Some people might be allergic to |
tsd
is in need of a refresh. I think it can be improved and a 1.0 version released.Table of Contents
Improvements
index.d.ts
RequirementIdeas
eslint-plugin-tsd
@tsdjs
/@tsdts
Improvements
Addressing issues with
tsd
.Remove
index.d.ts
RequirementOne of
tsd
’s biggest pain points is itstypings
file requirement. Here's just some of the issues expressing confusion or frustration with it:index.d.ts
does not exist #92index.d.ts
does not exist. Create one and try again #134index.d.ts
does not exist. Create one and try again. #135typingsFile
need to be specified? #195tsd
should be updated to work without one - whether that be on pure TypeScript projects, or on plain JavaScript inputs. As part of this, options relating to thetypings
file should be removed - more on that in CLI Overhaul and API Updates.CLI Overhaul
tsd
's CLI is bound to projects with apackage.json
and anindex.d.ts
file. Many other tools run on glob input, and search for configuration files in the current directory if none are provided. I thinktsd
should do the same, and have a new--package
option for testing a package's entry-point(s):This would make the
--typings
and--files
flags obsolete.API Updates
Besides updates related to adding/removing options mentioned above, the API's return value should be updated to report more information. Currently, it only returns an array of
Diagnostic
s. Returning an object allows adding more information in the future without breaking changes (#75 (comment)). For example, it could report the number of tests run:Programmatic usage of
tsd
should also be able to work without apackage.json
. Current behavior could be maintained with ausePackageJson: true
option, like the CLI's--package
. Maybe aninput: string[]
orfiles: string | string[]
option could be added to test string/file sources (which would resolve #86).Assertions Improvements
Assertions can currently fail in unexpected ways (#141, #190). Possible improvements:
const
type parameters, introduced in TypeScript 5.0Using
tsd-lite
’s assertion type definitions:I'd also like to extend
expectError
to support specific errors:This can be an escape hatch as an alternative to the warning added in #178.
Configuration Schema
Currently,
tsd
’s CLI can be configured via flags or atsd
field in a project’spackage.json
. We should export a JSON schema so users can get autocomplete/ errors / etc. when using the latter. This should be built from a TypeScript definition so we don’t have to duplicate anything.In the future, if we decide to support more configuration locations (e.g. a
.tsd.config.json
), having an exported schema would be beneficial.The
package.json
config should also support all of the available options (#198).Documentation Rewrite
The readme is convoluted in places. I think adding a
docs/
,recipes/
, and anexamples/
folder (similar toAVA
) where we could separate concerns would help organize things. The readme then could document installation and basic CLI/API usage.Internal Improvements
Some ideas for maintaining
tsd
:index.d.ts
requirement #186)ts-node
,tsx
)ts-api-utils
to simplify interacting with the TS compilerSupport Additional Extensions
We should add
.mts
and.cts
files to the default input path (#197).Ideas
Things that can complement/improve
tsd
.These are all "nice-to-haves", and the other improvements above have priority.
Test Multiple TypeScript Versions
Currently,
tsd
comes with a specific patched version of TypeScript as a direct dependency, and its version only changes whentsd
itself is updated. While some work was done to allow testing multiple versions in #47, some other potential solutions are:BYOTS
ts-expose-externals
ts-patch
@tsd/typescript
as a peer dependency - like intsd-lite
unleashed-typescript
- as mentioned in Allow testing another TypeScript version #47 (comment)eslint-plugin-tsd
An ESLint plugin that checks
tsd
usage and reports assertion failures, similar toeslint-plugin-expect-type
. This could then suppress errors from the TypeScript compiler from being reported when usingexpectError
. An alternative to #44, this could integrate with ESLint editor plugins and save us from writing one.Test Runner Integrations
jest-runner-tsd
is an extension for Jest that usestsd-lite
to reporttsd
type tests as Jest tests. Perhaps we could have similar integrations for other test runners, like AVA. Another nice feature would be usingtsd
in actual tests:Type Quality Checks
We could optionally report type coverage (#63) and type memory usage (#34), among others. Perhaps this could be integrated with the potential
eslint-plugin-tsd
.@tsdjs
/@tsdts
I think it’s time that
tsd
and@tsd/typescript
are moved to their own organization on GitHub, especially if some of these other ideas are implemented (plugins, test runner integrations, etc.)Thoughts? I’d love to hear any other improvements or ideas anyone might have, or any concerns with my suggestions.
cc: @sindresorhus @BendingBender @skarab42 @mrazauskas
The text was updated successfully, but these errors were encountered: