Initial Implementation

[Uzlopak]

This is the first implementation of the swagger-ui plugin.

Only options which effect the exposeRoute and the swagger-ui from @fastify/swagger should be covered by this plugin. exposeRoute as an option was removed, as it is implied that we want to expose the routes if we use this plugin.

Let us talk about if the initial options and separation is fine.

Still have to fix some tests, but it should already be self explainatory.

So please let us discuss if it is meeting our needs.

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[Fdawgs]

Can get rid of .npmignore if it is an exact copy of .gitignore, as NPM will fall back to using .gitignore if no .npmignore exists. See https://docs.npmjs.com/cli/v8/using-npm/developers#keeping-files-out-of-your-package

[Uzlopak]

removed the .npmignore

I still have to reactivate some unit tests and then it should be good to go.

[mcollina]

lgtm

[fmenis]

@Uzlopak I don't really agree with exposeRoute as an option was removed, as it is implied that we want to expose the routes if we use this plugin.
Imho, the exposeRoute configuration is very useful.

So, from version 8, if we don't want to expose the routes documentation in production, we must not register the plugin at all?
Before version 8, it was very easy exposeRoute: process.env.NODE_ENV !== ENV.PRODUCTION

[Eomm]

Note that you need to write:

if(process.env.NODE_ENV !== ENV.PRODUCTION){
  fastify.register(swaggerUi)
}

What would be a better option?

[fmenis]

@Eomm for me, the best option would be the one exposed by the exposeRoute flag.
I find it more elegant than dynamically registering the plugin.
But it doesn't matter, as you (and I in the first post) indicated, just register the plugin dynamically and all works fine.