Fastify v4 release coordination

[mcollina]

This is an issue to coordinate the release of Fastify v4. It will be updated as soon as it progresses.

---

• release new major of fast-json-stringify https://github.com/fastify/fast-json-stringify/releases/tag/v3.0.0
• create type providers modules Create fastify-type-provider-* modules #3404
• finish off all outstanding issues and PRs labeled v4: https://github.com/fastify/fastify/issues?q=is%3Aopen+is%3Aissue+label%3Av4.x and https://github.com/fastify/fastify/pulls?q=is%3Aopen+is%3Apr+label%3Av4.x
• prepare release notes & blog post
• check if anything needs to be done to support pino transports & pino pretty deprecation
• prepare the list of modules to update
• decide if we want to drop Node v12 support
• drop Node v12 as well as v10 from everywhere build: drop node 12 support #3532
• sync fast-json-stringify next branch and release it (https://github.com/fastify/fast-json-stringify/tree/next)
• implements Should array support in validation be enabled by default? #2852 by editing https://github.com/fastify/ajv-compiler ’s defaults major (ETA ~1h)
• create a fjs-compiler module in the fastify’s org:
  • supersedes Ajv serializer ajv-compiler#45 (using the fast-json-stringify@next)
  • supersedes upgrade fast-json-stringify with ajv8 #3280
• review/support feat: listen to multiple hosts by default #3546
• remove preParsing hook from two fastify’s modules Alias preParsing to onRequest hook. Deprecate preParsing #3503 (comment)
• implement deprecation warning Alias preParsing to onRequest hook. Deprecate preParsing #3503
• implement Invalid character in header content ["location"] error when redirecting to url with unicode encoded character in query parameters #3217
• Update all the core modules, for each one of them the following must be done:
  1. Open a PR updating Fastify to v4.0.0-rc.x
  2. Link the PR in the underlining list
  3. Once merged, release a new version of the module under the next dist-tag (npm publish --tag next)
  4. check module@latest is still correctly pointing to the old version with npm show
  5. tick the box in the underlining table
• publish blog post
• open issue at https://github.com/github/release-radar

---

Modules to update

Once one it's done add the PR link next to it.

• aws-lambda-fastify - feat!: update to fastify@v4 aws-lambda-fastify#108
• create-fastify
• @fastify/accepts - Update to Fastify v4 fastify-accepts#131
• @fastify/accepts-serializer - Update to Fastify v4 fastify-accepts-serializer#77
• @fastify/auth - Updated to Fastify v4 fastify-auth#154
• @fastify/autoload - Update to Fastify v4 fastify-autoload#239 - mostly not needed, the plugin just works.
• fastify-awilix - Updated to Fastify v4 fastify-awilix#73
• @fastify/basic-auth - Updated to Fastify v4 fastify-basic-auth#91
• @fastify/bearer-auth -Updated to Fastify v4 fastify-bearer-auth#134
• @fastify/caching - feat!: upgrade to fastify@v4 fastify-caching#102
• @fastify/circuit-breaker - Update to Fastify v4 fastify-circuit-breaker#90
• fastify-cli - feat!: migrate to fastify@v4 fastify-cli#490
• @fastify/compress - Update to Fastify v4 fastify-compress#224
• @fastify/cookie - Updated to Fastify v4 fastify-cookie#181 (no changes needed)
• @fastify/cors - Updated to Fastify v4 fastify-cors#201
• @fastify/csrf-protection - Updated to Fastify v4 csrf-protection#89
• @fastify/diagnostics-channel - Updated to Fastify v4 fastify-diagnostics-channel#39 - not many changes needed, only in tests
• @fastify/elasticsearch - feat!: update to fastify@v4 fastify-elasticsearch#77
• @fastify/env - Update to Fastify v4 fastify-env#144
• @fastify/etag - Updated to Fastify v4 fastify-etag#82
• @fastify/express - Update fastify 4 fastify-express#86
• @fastify/flash - Bumped Fastify v4 fastify-flash#71
• @fastify/formbody - bumped Fastify v4 fastify-formbody#111
• @fastify/funky
• @fastify/helmet - Bumped to Fastify v4 fastify-helmet#180
• @fastify/http-proxy - Update to Fastify v4 fastify-http-proxy#247
• @fastify/jwt - Updated to Fastify v4 fastify-jwt#227 (not many change needed)
• @fastify/leveldb - updated to Fastify v4 fastify-leveldb#93
• @fastify/mysql - Bumped Fastify v4 fastify-mysql#92
• @fastify/mongodb - Update to fastify@4 fastify-mongodb#179
• @fastify/multipart - Updated to Fastify v4 fastify-multipart#344 (no real change needed, only deprecations)
• @fastify/oauth2 skip because Update simple-oauth2 to v4.x fastify-oauth2#152
• @fastify/passport - feat: fastify v4 support fastify-passport#552
• @fastify/postgres - Updated to Fastify v4 fastify-postgres#131
• @fastify/rate-limit - Updated to Fastify v4 fastify-rate-limit#239
• @fastify/request-context - Updated to Fastify v4 fastify-request-context#114
• @fastify/response-validation
• @fastify/nextjs - blocked by chore(deps-dev): bump next from 12.0.8 to 12.1.6 fastify-nextjs#534
• @fastify/redis - Updated Fastify to v4. Dropped redis module support fastify-redis#147
• @fastify/reply-from - Update to Fastify v4 fastify-reply-from#250
• @fastify/routes - Updated to Fastify v4 fastify-routes#66
• @fastify/routes-stats blocked by Support Node v16 and v18 fastify-routes-stats#76
• fastify-schedule - Updated to Fastify v4 fastify-schedule#82
• @fastify/sensible - Updated to Fastify v4, dropped error handler fastify-sensible#109
• @fastify/secure-session - bumped Fastify v4 fastify-secure-session#130
• @fastify/session - update to Fastify v4 session#89
• @fastify/static - Update to fastify@4 fastify-static#292
• @fastify/swagger - feat: support fastify v4 fastify-swagger#599
• @fastify/websocket - Update to Fastify v4 fastify-websocket#197
• @fastify/url-data - Update fastify v4 fastify-url-data#104 (work as is, no need to update urgently)
• middie - Updated to Fastify v4 middie#144
• point-of-view - update to Fastify v4 point-of-view#309
• under-pressure - update to Fastify v4 under-pressure#162

[zekth]

Shouldn't we make a proper documentation review before landing v4? I know there were several corrections regarding phrasing / misleading sentences.

[mcollina]

Shouldn't we make a proper documentation review before landing v4? I know there were several corrections regarding phrasing / misleading sentences.

I don't think it's feasible. We need to ship a v4 release to get on the latest Ajv and Pino bandwagon, otherwise we are keeping ourselves further behind. Moreover there are quite a few improvements sitting in the next branch. I would also like to phase out Node v10 support asap (and possibly v12).

[jsumners]

Agreed that docs shouldn't block (despite the mess). Just drop 12 and below. Our release cycle is too slow to carry that forward.

[jsumners]

[ ] prepare the list of modules to update

I think we decided to move to @fastify/. So the list is: all of them. Which means I need help with https://github.com/fastify/deprecate-modules

Here's the thing: I am surfing the edge of burnout. I'm doing what I can to stay in the game at work, but OSS in my free time is really hard right now (I suspect the same is true of several of us). There's a mountain of things I want to get done here, in Pino, ldapjs, and my personal projects, but I just can't spend so much time on it.

[mcollina]

Thanks for the transparency @jsumners! I think a lot of us are in the same mindset at the minute.

[Fdawgs]

+1 on dropping support for node 10 and 12. Can mass remove them from CI workflows etc. if/when needed (or hopefully just the composite action if that's in place beforehand).

[climba03003]

Do anyone in @fastify/typescript have time to investigate on merging generic params for FastifyInstance and the others?
If nobody have time to do so, I think it should be left for the next main version.

[darkgl0w]

I am +1 on dropping support for Node.js 10 and 12.

[Ethan-Arrowood]

@climba03003 do you have something I can look at for

merging generic params for FastifyInstance

[climba03003]

@climba03003 do you have something I can look at for

merging generic params for FastifyInstance

For example

fastify/fastify.d.ts

Lines 29 to 34 in 08877f1

	declare function fastify<
	Server extends http2.Http2SecureServer,
	Request extends RawRequestDefaultExpression<Server> = RawRequestDefaultExpression<Server>,
	Reply extends RawReplyDefaultExpression<Server> = RawReplyDefaultExpression<Server>,
	Logger extends FastifyLoggerInstance = FastifyLoggerInstance
	>(opts: FastifyHttp2SecureOptions<Server, Logger>): FastifyInstance<Server, Request, Reply, Logger> & PromiseLike<FastifyInstance<Server, Request, Reply, Logger>>

should be changed to

// name can be changed
interface CommonServerInterface {
  Server = unknown, 
  Request = unknown, 
  Reply = unknown, 
  Logger = unknown 
}

declare function fastify<CommonServerInterface>(opts: FastifyHttp2SecureOptions<CommonServerInterface>): FastifyInstance<CommonServerInterface> & PromiseLike<FastifyInstance<CommonServerInterface>>

I don't know if it is possible, but a single interface here provide better DX if user want to override Logger only.

[Ethan-Arrowood]

Ahh yeah i've tried that once before and couldn't get it to work; maybe I'll try it again (but other folks should feel free to give it a shot + we don't have to block v4 for it)

[mcollina]

I have successfully merged main into next. I will soon create a v3.x branch and move next to main.

[luisorbaiceta]

Should we make a dedicated section with release notes in our homepage?

[jsumners]

We leverage the GitHub releases feature to publish release notes.

[luisorbaiceta]

I'm aware. But I feel like there's people that miss those and instead just rely on our website documentation.

The section wouldn't be something too extense, just the news about a new major version and a short description of the new features (and fixes?).

I see that there was a blog post planned too. We could also link it from the site.

[Fdawgs]

Like the V3 migration guide but for V4?

[luisorbaiceta]

Like the V3 migration guide but for V4?

That could be added too!

So apart from the github releases feature to publish release notes we could:

• Make a short banner/section in our homepage to announce the release (this could include a link to the above mentioned blog post). This would be a short list with the key new improvements and a short description.
• Migration guide doc page (Under a new migrations toc section maybe?)

Some examples:

[josh-hemphill]

In #3083 there was some consensus about changing the default of jsonShorthand to be disabled in the next semver major.
Now that AJV support is externalized, I'm not sure if switching to AJV JTD by default could be considered, but it would provide automatic type inference on request objects and would be a lot more concise, which is what the whole jsonShorthand was meant to do in the first place. (Might need to also clarify, AJV can still export JSON Schema definitions based on JTD, so it wouldn't effect any OpenAPI exports etc.)

[climba03003]

Not stale, it is in progress.

[Fdawgs]

Stalebot getting inpatient 😆

[mcollina]

I have updated the table at the top adding the full list of modules. Let's start updating them all! If you have some time this is a great way to contribute.

[jsumners]

These will be new major versions. Do not forget to update the name in the module metadata.

[Fdawgs]

https://github.com/fastify/fastify-bankai is archived, so can be removed from the list.

[mcollina]

Hey folks, I've covered most of the plugins in the list. I plan to have Fastify v4 released between now and OpenJS World in Austin.

[mcollina]

Feel free to take a stab at the remaining ones.

[jsumners]

Amazing work. I know how tedious that must've been.

[Retro64]

Really looking forward for the 4.x release. Great work! @mcollina One question: Is fastify-plugin intentionally missing in the list "modules to update"?

[mcollina]

It does not need an update.

[metcoder95]

Hi! Made a couple of PRs for @fastify/caching and @fastify/elasticsearch, I'll try to open more during the day/week 🙂

[mcollina]

I think we are almost ready to ship. I plan to issue a release after or during the Collaborator Summit in Austin.

[jsumners]

The modules issue still has a few things that need to be resolved.

[mcollina]

I'm happy to ship without those for now

[josh-hemphill]

I commented a while back about changing defaults and doc examples to JTD by default instead of JSON Schema. Some of that lies with ajv-compiler, but the jsonShorthand default currently has to be disabled by the user to use JTD schemas with the ajv-compier, which isn't a great experience for new users who want to use JTD.
I saw there was mention of putting off some changes so that v4 can land with the dependency upgrades, so perhaps changing the default could be pushed to something like v4.1; someone using JSON Schema syntax may perceive it as a breaking API change, but it is only a single option that changes the schema interpretation in some specific cases, so perhaps it could be defended as a semver minor change if necessary.
Just want to make sure it doesn't get overlooked if it needs to be in v4.

[mcollina]

I think we'll go with JSON Schema with the v4 line. I'd be happy to review a PR that documents JTD as an option.

[jsumners]

I do not think JTD is a sufficiently widely adopted standard across languages to make it the default. JSON Schema enables interoperability among many different ecosystems.

[mweberxyz]

Regarding "check if anything needs to be done to support pino transports & pino pretty deprecation" -- in my recent testing my application started throwing deprecation warnings like:

(node:56488) [PINODEP008] PinoWarning: prettyPrint is deprecated, look at https://github.com/pinojs/pino-pretty for alternatives.

As suggested here the deprecation warnings go away by changing my config from:
fastify({logger: { prettyPrint: true}})
to
fastify({logger: { transport: { target: 'pino-pretty' }}})

I am seeing no other problems with newest pino and pino-pretty otherwise. If this is the case, the only needed change would be a documentation update. I'd be happy to create a PR to update the logging documentation if no one has picked it up yet.

[mcollina]

Go for it! Thanks!