Plugin compatibility checks mismatch when comparing beta with canary compatibility

[zachleat]

Found out via https://github.com/11ty/eleventy-plugin-webc/pull/43 from @colinaut

Ended up discovering a new thing about semver, that prerelease tags are… alphabetic

https://semver.org/#spec-item-11

This only presents a problem when you’re trying to use a beta release 👀 on a plugin that has canary compatibility, especially if that plugin requires a specific minimum version of canary:

• eleventy-plugin-vite requires >=2.0.0-canary.4
• eleventy-plugin-webc requires >=2.0.0-canary.19

Practically speaking, if we change these plugins to require >=2.0.0-beta.1 they will now match all valid canary versions (which is bad).

As they currently stand, they do not match the beta release but only issue a console.warn and keep processing gracefully.

All other official Eleventy plugins do not tie to a specific canary release for compatibility and as such are unaffected.

(source: https://fediverse.zachleat.com/@zachleat/109717715197804907)

[zachleat]

Also just as a note for me the versionCheck method was modified to add support for prereleases in 1.0 via https://github.com/11ty/eleventy/issues/2001

[colinaut]

Well that's not something I would have expected. I would have thought it would count them as completely different rather than just letters to be listed alphabetically. Good catch there.

[zachleat]

I think moving forward we’ll want to standardize on alpha instead of canary for prereleases in 3.0.

[zachleat]

Shipping with 2.0.0-beta.2

[colinaut]

I think moving forward we’ll want to standardize on alpha instead of canary for prereleases in 3.0.

Aww I liked the playfulness of canary. alpha is jejune. How about another bird that is also alphabetical like albatross or ashy-throated-bush-tanager or apricot-breasted-sunbird?

I mean granted an albatross release might convey an entirely different meaning than a canary release. :)

[colinaut]

Heads up: I just discovered that this semver issue also effects pnpm. If I have "@11ty/eleventy": "^2.0.0-beta.1" in my package.json and do an install using pnpm install in installs 2.0.0-canary.33 rather than 2.0.0-beta.1. However if I do a npm install it works fine.

Not sure if your fix in core will fix this too but it would be nice as I like to use pnpm.

[KiwiKilian]

A strong 👍 on adhering to semver for the next pre-releases. As visible in this screenshot from https://semver.npmjs.com/ it also affects every normal npm install.

I do have a plugin which dependens on @11ty/eleventy – with a loose depency like @11ty/eleventy@^2.0.0-canary.1 and the parent project using @11ty/eleventy@2.0.0-beta.1. This caused the plugin to install its own latest canary causing errors in the build as main project and plugin used different @11ty/eleventy versions.

Also interesting 11ty.compatibility behaves quite differenty to npm installation ranges:

While this would not install a 2.0.0-prerelease, 11ty.compatibility will not complain about a mismatch. Is this supposed to behave differnt?

So basically my plugin would use something like this (beginning with beta as it's "lower" thant canary):

  "11ty": {
    "compatibility": ">=1.0.0-beta.5"
  },
  "peerDependencies": {
    "@11ty/eleventy": ">=1.0.0-beta.5 || >=2.0.0-beta.1"
  },

This still has a caveat, it's not possible to allow prereleases of all above versions.

[zachleat]

Just to minimize the impact of this issue I will release a new canary with each beta so they’ll match in functionality at least.