-
Notifications
You must be signed in to change notification settings - Fork 53
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
Remove openapi3-ts exports #150
Conversation
These exports seem wrong, you can just import directly from the `openapi3-ts` dependency without going through this library. On top of that, they are actually the source of an error when using this project as a dependency in a `yarn` project: ``` Module not found: Can't resolve 'openapi3-ts/oas30' in '[...]/node_modules/@asteasolutions/zod-to-openapi/dist' ``` I believe it's safe to remove them, was there any specific reason why they were added?
@dmarcato I believe the idea back when we were using the older version was to reexport the types if anyone needed them (without having openapi3-ts as a direct dependency). The overall idea was that you can do something like: import type { OpenAPI } from '@asteasolutions/zod-to-openapi';
// use it as:
const schema: OpenAPI.SchemaObject = { ... ] I don't think it was ever "requested" and it being something strictly important so I'd be down to remove it. However I am kind of confused why you would get such an error in the first place. Seeing that you mentioned:
is it possible that you have |
Since import * as OpenAPIV3 from 'openapi3-ts/oas30'; without having to explicitly add a direct dependency to To be honest I'm not 100% sure why I'm getting that error either, I don't have a direct dependency on |
@dmarcato Hey. I'm not sure importing directly from a transitive dependency is valid 100% of the cases - if the transitive dependency isn't hoisted or there is another bundler which doesn't support it then it may not be possible. Or if you have a linter such as eslint there is a rule usually to have all dependencies declared in package.json. Can you try changing the lines to: export type * as OpenAPIV3 from 'openapi3-ts/oas30';
export type * as OpenAPIV31 from 'openapi3-ts/oas31'; Note the addition of If the above doesn't work - I'm fine with removing the reexports |
I am also seeing the issue of In my case it's where the package that depends on zod-to-openapi is used by another package (I have a schema package that depends directly and then another package that depends on the schema package). All of this is done locally via hoisting in npm workspaces. As with the requestor I have the package downloaded in my node_modules but it's struggling to find it when running in the dependent package. It could just be some misconfiguration my side but I agree if it's not needed it can be removed. If a package needs Workaround to unblock: |
Sorry for the delay here - what @samkio described is exactly the same use-case I have and the reason why I created this PR. From the comments here it seems like this was done for an hypothetical ease of use, but seems like it's creating more issues than value. I believe right thing to do is to remove the export and force people to declare an explicit dependency on |
These exports seem wrong, you can just import directly from the
openapi3-ts
dependency without going through this library.On top of that, they are actually the source of an error when using this project as a dependency in a
yarn
project:I believe it's safe to remove them, was there any specific reason why they were added?