-
-
Notifications
You must be signed in to change notification settings - Fork 320
Add plugin for Hey API #1132
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
base: main
Are you sure you want to change the base?
Add plugin for Hey API #1132
Conversation
commit: |
|
To pass my tests, since I'm using |
|
Yeah please see other plugin fixtures |
|
@webpro Should be better now! |
webpro
left a comment
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.
Nice one! Just a few small issues left I think.
| const resolveConfig: ResolveConfig<PluginConfig> = async (config): Promise<Input[]> => { | ||
| const plugins = (config.plugins ?? []).map(plugin => { | ||
| const pluginName = typeof plugin === 'string' ? plugin : plugin.name; | ||
| return toDeferResolve(pluginName); |
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.
If the plugins are always dependencies (i.e. not local files) we can use toDependency (it's faster as there's no need to resolve anything on the fs).
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.
Done!
Co-authored-by: Lars Kappert <[email protected]>
Co-authored-by: Lars Kappert <[email protected]>
Co-authored-by: Lars Kappert <[email protected]>
Co-authored-by: Lars Kappert <[email protected]>
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.
Pull Request Overview
Adds a new "hey-api" plugin to detect dependencies and generated entries from Hey API OpenAPI-TS configs.
- Introduces
hey-apiin plugin registration, schema, and type definitions. - Implements
hey-apiplugin logic to detect@hey-api/openapi-tsusage and resolve dependencies plus generated file globs. - Adds fixtures and a basic test to verify counters for the new plugin.
Reviewed Changes
Copilot reviewed 16 out of 16 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| packages/knip/src/types/PluginNames.ts | Registers 'hey-api' in the plugin name union and list |
| packages/knip/src/schema/plugins.ts | Adds schema entry for the 'hey-api' plugin |
| packages/knip/src/plugins/index.ts | Imports and exposes the hey-api plugin |
| packages/knip/src/plugins/hey-api/types.ts | Defines PluginConfig for hey-api |
| packages/knip/src/plugins/hey-api/index.ts | Implements isEnabled, config patterns, and resolveConfig for hey-api |
| packages/knip/schema.json | Adds JSON schema definition for hey-api |
| packages/knip/test/plugins/hey-api.test.ts | Adds test to ensure hey-api plugin counts files |
| packages/knip/fixtures/plugins/hey-api/* | Provides package, config, and generated SDK fixtures |
Comments suppressed due to low confidence (2)
packages/knip/test/plugins/hey-api.test.ts:10
- [nitpick] Add a test case for when
config.outputis provided as an object (with apathproperty), such as in the CJS config, to verifyresolveConfigincludes the correct entries.
test('Find dependencies with the hey-api plugin', async () => {
packages/knip/src/plugins/hey-api/types.ts:1
- PluginConfig is missing the required 'input' property that the Hey API config uses (e.g.
input: string;). Add it to align with the UserConfig interface from @hey-api/openapi-ts.
export type PluginConfig = {
|
@webpro I'm not sure how to debug this CI error, and I don't see that I have the option to rerun the failed checks. https://github.com/webpro-nl/knip/actions/runs/15637574744/job/44056620965?pr=1132 |
webpro
left a comment
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.
Is there a public repo available where we can exercise this plugin to make sure loading config files works fine and we're not missing something obvious?
| return acc; | ||
| } | ||
|
|
||
| const dependencies = plugin._dependencies ?? []; |
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.
Is there documentation or code available regarding this _dependencies property?
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.
Hmm. When I look up types in my local machine, I find this:
interface Meta<Config extends BaseConfig> {
/**
* Dependency plugins will be always processed, regardless of whether user
* explicitly defines them in their `plugins` config.
*/
_dependencies?: ReadonlyArray<AnyPluginName>;
// ...
}But when I look in their repo I find this:
interface Meta<Config extends BaseConfig> {
/**
* Dependency plugins will be always processed, regardless of whether user
* explicitly defines them in their `plugins` config.
*/
dependencies?: ReadonlyArray<AnyPluginName>;
// ...
}When I look at their docs it shows dependencies being set in the custom plugin's config, but it also says this:
Reserved fields are prefixed with an underscore and are not exposed to the user.
So as best I can tell, it's specified as dependencies in the custom plugin's configuration, and then is changed to _dependencies when the plugin is loaded in.
That said, since this is all a bit vague, and their docs says the custom plugin API is currently unstable, maybe I should remove the custom plugin support from this PR for now?
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.
maybe I should remove the custom plugin support from this PR for now?
Not sure. Is there a public repo available where we can exercise this plugin to make sure loading config files works fine and we're not missing something obvious?
5a2d249 to
6bd250a
Compare
Just created one: https://github.com/narthur/hey-api-demo I included a custom plugin in that repo. Its types forced me to use I also discovered that in some places in their docs they show including default plugins when adding your own plugins: https://heyapi.dev/openapi-ts/plugins/tanstack-query#installation Which means I need to figure out how to make the knip plugin handle that without flagging those default dependencies as unlisted. |
|
Trying to think this through... feels like a bit of a catch-22. If the user interpolates default plugins and I allow them through as usual, they may be caught as unlisted. If I instead filter out default plugins from the user's provided plugins, then they may end up flagged as unused if the user also includes them in their direct dependencies. I'm leaning toward just letting them through and allowing them to be caught as unlisted.
|
|
We could do something like this for the default plugins: const defaultPlugins = ['@hey-api/typescript', '@hey-api/sdk'];
const plugins = (config.plugins ?? []).reduce<Input[]>((acc, plugin) => {
if (typeof plugin === 'string') {
if (!defaultPlugins.includes(plugin)) acc.push(toDependency(plugin));
return acc;
}From a Knip perspective, are |
|
@webpro Seems like it's working well now, both by test and demo. Maybe ready for another review? |
|
There's quite a few projects using it seems: https://github.com/hey-api/openapi-ts/network/dependents, we don't we check some of those out and smoke-test a bit? My guess is that this might shed some light to some of the doubts we're having? |
|
Hmm, interesting. I wonder if there's a way I can filter that list for projects that use Hey API. |
|
Looks like this is the search to do that: https://github.com/search?q=knip+%40hey-api%2Fopenapi-ts+path%3A**%2Fpackage.json&type=code |
|
The page I linked to is the list of projects using Hey API which this PR adds a plugin for. If any of those projects is already using Knip that's cool, but what we're mostly interested in is the configuration any project using Hey API does not need with this Knip plugin added. If a project is using Hey API and Knip, and assuming the Knip configuration was good, then what we want to see is the Knip configuration they can remove due to the new plugin. To this end, I'll test drive a few projects in the coming days. |
|
@webpro Gotcha, ok. I've reverted my additions to the automated tests since it sounds like that wasn't the correct way to do this. |
|
For what it's worth, I've installed this version of Knip in the project that initially prompted me to make this PR, and it's working well so far. |
This PR adds a plugin for Hey API.
https://heyapi.dev/