feat: move openapi-types and @standard-schema/spec to deps

[belgattitude]

Although I understand the reasoning, I feel that those should be declared as regular deps rather than peer-dependencies.

As I understood this is mostly type definitions... but I feel moving them to deps might help installation (peer-deps aren't installed by default with all package managers/configs/version, and it might make sense to keep them hoisted to @standard-community/standard-api if an application uses a different version (openapi-type v11 for example)

Consider this PR to be we a suggestion. Not a must have

PS: There's of course a risk with type only packages... when we have duplicate (pnpm dedupe, yarn deduplicate... might help). But it's the same with peerdeps

[vladshcherbin]

They should be absolutely moved to dependencies, came here to raise same issue and saw your PR 🙌

[MathurAditya724]

Honestly, these will bloat the package and for the most cases many won't even need them. Also the docs of Standard Schema also says that it's not needed as the package depen.

Adding it as a peer depn. makes the package managers auto download them or else they can download it themselfs too if they have switched off the Auto Install Peer Depen Stuff.

I suggest that it would be better to add about this in docs maybe, rather then this. What do you guys think?

[belgattitude]

Hey @MathurAditya724

it themselfs too if they have switched off the Auto Install Peer Depen Stuff.

Is that true for npm and yarn 1,2,3,4... ?

Autodownload is default on pnpm

In my experience, pnpm deduplication won't be done consistently with peer-deps... It probably stabilized around v9 or something.

But in bigger projects I can imagine people want to disable this automatic behaviour to reduce install sizes

these will bloat the package

No difference in install because it either will be silently installed or will require explicit addition by the consuming app/package

By being in the deps, package managers are more stable about duplication (In general they will hoist only one version deduplicated in the root node_modules).

No difference in bundle size. They're types only

limitation of peer-deps... With peer-deps there's no immediate/easy way to install for example open-api types v5 and v11 (in the case a part of the code or packages require two semantically incompatible versions). With deps, they will be correctly hoisted in the node_modules folder. When autoinstalling peer-deps, if you import from ie standard schema, somehow you import a non declared dependencies... Not very clear which version is installed (for type only it's okay... but with recent supply chain attacks it's less intuitive)

Also the docs of Standard Schema also says that it's not needed

I saw that too... I don't know their motivations and it's not rare that some publisher choose peer deps / optional or not.

But I'd say for standard-schema/spec in peers why not ? I don't have something against especially that it could be considered as a general requirement for any project like @types/react or @types/node (while still in favour of deps but I'm not enough informed).

For openapi-types, imho it's definitly a dep, not a peer dep.

Let me know I can rebase and propose something