Deprecating fastify-* modules

[jsumners]

2022-05-07 remaining work:

The following list is hoisted from comment #3733 (comment)

• aws-lambda-fastify
  • Rename package (Rename Module aws-lambda-fastify#110)
• fastify-auth
  • Update dependencies (Updated to Fastify v4 fastify-auth#154)
• fastify-awilix
  • Update dependencies (Updated to Fastify v4 fastify-awilix#73)
• fastify-csrf
  • Rename package
• fastify-flash
  • Update dependencies
• fastify-schedule
  • Update dependencies (Updated to Fastify v4 fastify-schedule#82)
• fastify-session
  • Missing release notes
  • Update dependencies
• fastify-swagger
  • Update dependencies
• middie
  • Rename package (Rename module middie#148)
• point-of-view
  • Rename package (Rename module point-of-view#325)
• under-pressure
  • Rename package (Rename module under-pressure#166)
• any-schema-you-like
  • Rename package (Rename module any-schema-you-like#25)

---

Original post:

Issue

If we are going to deprecate fastify-* modules, as outlined in #3482 (comment), then I really need help with https://github.com/fastify/deprecate-modules.

To start, I need help auditing https://github.com/fastify/deprecate-modules/blob/a7a87b05d129e04d7e36bd4f0eb07d479e2d7b6f/lib/modules.json to determine:

1. Is the list of modules correct
2. Are the versions correct? versionToPublish will be the new fastify-* version for the module. The newModule.version will be the version published under @fastify/*.

Subsequent to that, I need help with the todo list in the readme. In particular, is there anything that needs to be done for TypeScript in the deprecated modules (look at the templates)? How should the templates be updated for ESM exports?

Once we have the deprecation portions written and tested, we need to work on adding script for:

1. Updating GitHub repository information (rename the repo, update links in package.json, etc)
2. Patching the package.json with the new name and version for the new @fastify/* packages

attn: @fastify/core

[zekth]

Could we make a checklist for each package like:

fastify-cors:

• Fastify 4 compliant
• Upgrade version OK
• Template compliant. (doc / typescript )

[jsumners]

Please do.

[darkgl0w]

I am looking at modules.json list and so far :

• there is one missing package that I will add via a PR (e.g.: aws-lambda-fastify renamed to @fastify/aws-lambda or something better), that part is trivial. EDIT: should it be added to this list 🤔 ?
• there are some special cases (like fastify-csrf that will collide with already existing packages as we have another package published as @fastify/csrf), IMO these packages will require a manual intervention
• after navigating through all the org repos, there seems to be some repo that needs to be archived :p

[zekth]

Project has been created: https://github.com/fastify/deprecate-modules/projects/1

[mcollina]

@zekth we will be changing name and bumping major and then migrate to fastify v4 and bump major again.

[zekth]

@zekth we will be changing name and bumping major and then migrate to fastify v4 and bump major again.

Right now we're doing straight deprecation and work with the compatibility and compliancy afterward so?

[mcollina]

yes exactly

[jsumners]

As currently written:

  {
    "name": "fastify-cookie",
    "versionToPublish": "5.7.0",
    "license": "MIT",
    "newModule": {
      "name": "@fastify/cookie",
      "version": "6.0.0"
    }
  },

The following would happen:

1. A new fastify-cookie package would be published at version 5.7.0 (up from 5.6.0). This package will wrap the exports of 5.6.0 with a deprecation notice.
2. A new @fastify/cookie package would be published at version 6.0.0. This package will have the same code as 5.6.0.

Any subsequent changes to comply with fastify@4 would bump @fastify/cookie to 7.0.0.

This is the correct plan, yes?

[mcollina]

amazing!

[yaneony]

What about "point-of-view" plugin? Maybe it makes sense to rename it as @fastify/views ?

[jsumners]

What about "point-of-view" plugin? Maybe it makes sense to rename it as @fastify/views ?

This one does get skipped by the automated tool. I don't really have an opinion about moving it under the org scope. It's already named independently, and thus does not cause confusion around whether or not it is a community plugin or an org plugin.

[yaneony]

But isn't "point-of-view" one of org plugins?

[jsumners]

But isn't "point-of-view" one of org plugins?

Yes.

[yaneony]

But then, it makes sense to move it to org plugins as well. As of mine sight of view. Right now this plugin looks "out of scope" and not fastify related. Moving it to @fastify/views or @fastify/pov will make it look more fastify related.

Just only my 2 cents :D

[fox1t]

I like this plan! 👏

Speaking of point-of-view I vote for @fastify/point-of-view and it can follow the same upgrade path as others.

[mcollina]

I would just move it to @fastify/view

[jsumners]

Given that point-of-view does not conform to the other modules's naming style, it would be difficult to include in the automated tool. It should be done manually.

[delvedor]

I would keep the same name to avoid too much confusion, so @fastify/point-of-view.
Otherwise, @fastify/view works as well.
The same needs to happen for under-pressure.

[stale]

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.

[mcollina]

@jsumners is on it, hopefully shipping this in the next two weeks!

[RafaelGSS]

I think we can update the plugin docs explaining the latest version of each module is required Fastify v4

[jsumners]

I think we can update the plugin docs explaining the latest version of each module is required Fastify v4

Not sure I understand.

However, great job taking on the remaining modules.

[Fdawgs]

I think we can update the plugin docs explaining the latest version of each module is required Fastify v4

Not sure I understand.

I think what @RafaelGSS is saying is that the documentation for the plugins needs updating to state what plugin versions work with what Fastify versions, as we've had a few issues raised regarding it:

• Dependency version mismatch point-of-view#320
• Cannot use this plugin on fastify 3.x.x fastify-formbody#114

[jsumners]

I would not have recommended merging those PRs. My recommendation would have been to remove the prior notice of "use this version for this other thing's version". It's too much work to keep updated.

The mistake is releasing new final versions of plugins for v4 prior to v4 being released. Fastify should allow loading of prior versions of modules (see #3879 (comment)) and modules should not release new majors out of rc-phase until a corresponding final Fastify release is issued.

[jsumners]

I have added https://github.com/fastify/any-schema-you-like to the list.

[mcollina]

What names should we pick for those non-fastify-branded packages?

[jsumners]

I don't have much of an opinion on that. I'd just prefix them with the org scope and move on.

[RafaelGSS]

I suggest:

• middie -> @fastify/middie

• point-of-view -> @fastify/view

• under-pressure -> @fastify/under-pressure

• any-schema-you-like -> @fastify/any-schema-you-like

[Fdawgs]

Maybe cut down any-schema-you-like to any-schema?

[RafaelGSS]

The remaining list is officially done!

[jsumners]

Thank you for finishing the list @RafaelGSS. I feel bad that I got this thing started and then couldn't finish it.

@fastify/plugins I have removed all of the non-scoped packages from the plugins team on npmjs.com. They should not be getting any further updates, so the permissions should reflect that. Please raise an issue if you determine one needs a new version for some reason. We will coordinate with those who have permissions to do so.