fastify-static plugin as an option

[zekth]

Prerequisites

• [X] I have written a descriptive issue title
• [X] I have searched existing issues to ensure the issue has not already been raised

Issue

Currently we are embedding fastify-static to serve the swagger-ui. But what about the case when people want to use only the /json feature? I'm asking this because i sometimes have dependabots notifications like so: This can be solved by removing fastify-static from dependencies and add it as peerDependencies but i'm not a fan of it. What about adding it as an option?

[mcollina]

I don't understand, is there a vulnerability somewhere I didn't receive a report on?

[zekth]

It's an old one, but was stalling in one of my repositories. But in this project i don't use any feature involving the need of fastify-static that's why I'm bringing the point.

[mcollina]

Solving this is quite complex and require a lot of rework.

Just adding an option to pass in fastify-static does not work from my point of view. peerDependencies are not standardized across package managers and better avoid them. More importantly, they'll likely still be installed, causing your problem of having a dependency you do not need.

The root cause of your problem is that fastify-swagger does too much. It has 4 responsibilities:

1. generate the swagger definition from the routes
2. generate the openapi definition from the routes
3. expose the swagger endpoints
4. serve the swagger UI

I think the only solution is to move this to a monorepo/workspaces setup and split it in multiple modules. In the meanwhile we can also move it to the @fastify scope.

This is quite some work.

[zekth]

This is a good analysis of the current situation. A good roadmap would be to migrate to @fastify scope and refactor it afterward?

[mcollina]

It really depends if somebody has time to do the refactoring. It's not a big issue for most people.

[climba03003]

If it will be a rewritten version. I recommend to provide a plugin system (plugin registration order does matter). Allow the user to customize all the behavior as their needs.

We only provide the basic one, like openapi and swagger. And they can create an plugin like typebox, joi for extra support.

The below one is what I did to allow all behavior customization and support multiple document based on constraints / what you needs. https://github.com/climba03003/fastify-openapi

As an alternative, I use Elements to provide the document. It is more light weight and do not need fastify-static. https://github.com/climba03003/fastify-openapi/blob/6429e36b688ab7a0083116847ba2d3b3df4d8e12/lib/utils/routes.ts#L31-L57

[climba03003]

POC for my last comment in here https://github.com/climba03003/fastify-openapi/tree/next

import { TypeboxPlugin, OpenAPIPlugin, FastifyOpenAPI } from '@kakang/fastify-openapi'
import Fastify from 'fastify'

const fastify = Fastify()
fastify.register(FastifyOpenAPI, {
  // default: [OpenAPIPlugin]
  plugins: [TypeboxPlugin, OpenAPIPlugin]
})
await fastify.ready()
// documents calculated from first get
fastify.documents

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Fdawgs]

Want to throw a +1 in for this, in my projects fastify-swagger contributes 5-10% to the size of node_modules primarily because of fastify-static and the UI (which isn't used as I use Redoc to provide the frontend for the OpenAPI documentation).

[mcollina]

I agree, however we need somebody to champion this.

[Uzlopak]

How about we fork this repo in the fastify org and name it @fastify/openapi, and remove all the swagger-ui code. Maybe rename this package to @fastify/swagger-ui to make clear it adds only swagger-ui and requires @fastify/openapi-spec.

I personally prefer rapidodc of @mrin9 and I also would not need swagger-ui.

[mcollina]

I think we should:

1. create a new package @fastify/swagger-ui that just adds the Swagger UI.
2. remove everything @fastify/swagger-ui from this repo, pointing to the new repo for the docs
3. release a new major

This looks a good starting step, wdyt?

[Uzlopak]

If you give green light, I would take care of it.

[mcollina]

go for it

[magiclen]

The fastify.swagger() function is useful in my case (using exposeRoute = true). I don't want fastify-swagger to register any routes for me because I just need the fastify.swagger() function...

[climba03003]

The fastify.swagger() function is useful in my case (using exposeRoute = true). I don't want fastify-swagger to register any routes for me because I just need the fastify.swagger() function...

Please open a separate issue or submit a PR for your use-case.

[Uzlopak]

I already created a swagger-ui implementation in https://github.com/fastify/fastify-swagger-ui

I was waiting for feedback of you guys. It currently fails because cspNonce is already decorated to fastify.

https://github.com/fastify/fastify-swagger-ui/pull/1

[Uzlopak]

Solved with release of v 8.0.0