feat: webpack test stack

[zekth]

Aim to fix: #3158

So i've setup everything in a side test stack because this is not something we want to focus on when developing / fixing issues in fastify. Webpack and webpack-cli are kind of heavy weight packages and we don't want to arm developer experience with those.

Currently the bad version plugin registration will not make the build fail in the current state of fastify. I'm ok to land it this way untill we find a proper solution for the release process.

[mcollina]

lgtm

[mcollina]

I think we should add a bit of documentation somewhere about this.

[mcollina]

(a follow-up PR to fix this would be highly appreciated)

[zekth]

I think we should add a bit of documentation somewhere about this.

This PR was more of a POC to see if the team is ok for the implementation. I'll write a Readme on this bundler folder to explain how it works.

[mcollina]

Is this test going to pass or not? I'm not sure it would. Maybe we should skip it in case - I want all the CI to stay green.

[zekth]

So theorically on a non bundled environment it would fail, but on bundled environment because of the fallback in here:

fastify/fastify.js

Line 688 in a90c68b

return pkg.name === 'fastify' ? pkg.version : undefined

it's set to undefined. So it passes.

[mcollina]

Can you clarify the comment so that it's clear what we should change here?

[zekth]

Sure

[mcollina]

I think a simple solution for the webpack problem might be to store only the major within the source code. This does not create an addition of the maintenance burden and it provides a minimal version of this feature for bundled usage.

[jsumners]

I think a simple solution for the webpack problem might be to store only the major within the source code. This does not create an addition of the maintenance burden and it provides a minimal version of this feature for bundled usage.

In my opinion, that's effectively removing the feature. We routinely release new features as part of minor, and sometimes even patch, that define a new minimum version for applications. For example, if you want to access this.server in a decorator you should be specifying 3.17.0 as the minimum supported Fastify version.

[mcollina]

I think a simple solution for the webpack problem might be to store only the major within the source code. This does not create an addition of the maintenance burden and it provides a minimal version of this feature for bundled usage.

In my opinion, that's effectively removing the feature. We routinely release new features as part of minor, and sometimes even patch, that define a new minimum version for applications. For example, if you want to access this.server in a decorator you should be specifying 3.17.0 as the minimum supported Fastify version.

I'm happy to completely disable the feature for webpack usage.

[zekth]

Do we aim to land it this way and find a solution for the version resolution in a further pr? (should i rebase?)

[mcollina]

LGTM let's land this as is and then evolve.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.