rfc: make FAST Element a peer dependency of Foundation, Router, and SSR packages

[chrisdholt]

💬 RFC

🔦 Context

Currently the Foundation, Router, and SSR packages are tightly coupled to pinned versions of FAST Element. This can make upgrading certain versions of packages difficult from a consumer perspective, especially if certain versions are in conflict. While some package managers do a good job of resolving these deltas, it seems like setting these under "peerDependencies" will provide a better overall and more manageable experience. I believe most package managers will install these by default if not included, but it also seems quite reasonable to assume that if you're using these in your project, you're using FASTElement. The peer dependencies would reflect the most recent major version of FAST Element.

Outstanding questions:

• How does beachball play with peer deps? A cursory investigation shows it will potentially bump, though this should be something configurable...
• If configurable, should we do this for current Beta (allowable range with >2.0.0-beta as value)

[rajsite]

Alternate wording of my previous comment:

Forcing peerDependencies when it is not needed causes more potential headache for me. I have to resolve the peerDependency by fixing up package versions in order to ship (or choose too force overrides just to get things too build). Tends to break tooling like rennovate / dependabot on automatic upgrades. I don't have the option to ship a bulkier app temporarily that is still functional.

Missing peerDependencies when they are needed makes it easy for my app too get in a bad state. Globals may get overridden when two copies of the same library get compiled in and break each other in subtle ways. I have to manually track that I don't include multiple copies of the same library accidentally.

[chrisdholt]

Thanks for the comments @rajsite - by scoping specifically to FAST Element my hope is to remove headaches (and heartaches). Ultimately, if you're building with FAST Foundation, or using FAST SSR or Router, you've defined a version of FAST Element in your library or application. The goal here is to tell the lowest level and most fundamental portion of the library to use the version you have defined. IMO, this prevents duplication or conflicts and enables upgrading that core library only when you are ready or need to. With the current state of affairs, the library calls for set versions, so if you don't update FE along with Foundation, you're in resolution mode.

I think at this level, peer dependencies prevent the bloat by deferring resolution of FAST Element to your enumerated version rather than requiring resolution every update of a package we publish enumerating it as a dependency.

On the missing peer deps standpoint, the latest versions of both yarn and npm both will install non-enumerated peer dependencies by default. I believe pnpm would do the same.

All said, the intent here is to allow you to define the core library version you're building on and prevent mismatched dependencies.

[rajsite]

Actually I'll concede. It's unlikely most apps will need to leverage fast element / fast foundation based components from multiple disparate component library implementations.

I'm not aware of any other fast foundation-like libraries being shared in the community (though we would like to make one soon with menu-button, date-picker, and a few more not in fast-foundation yet).

So at least today you are unlikely to get stuck being forced to override peerDeps between libraries.

Though I will ask in response to:

If configurable, should we do this for current Beta (allowable range with >2.0.0-beta as value)

Is there a reason FF, et. al, in main is not using more normal semver specifiers like the archives branch instead of pinned?

fast/packages/web-components/fast-foundation/package.json

Line 98 in c64110d

"@microsoft/fast-element": "^1.12.0",

Is it an artifact of the prerelease tags that goes away in release?

[chrisdholt]

Actually I'll concede. It's unlikely most apps will need to leverage fast element / fast foundation based components from multiple disparate component library implementations.

I'm not aware of any other fast foundation-like libraries being shared in the community (though we would like to make one soon with menu-button, date-picker, and a few more not in fast-foundation yet).

So at least today you are unlikely to get stuck being forced to override peerDeps between libraries.

Though I will ask in response to:

If configurable, should we do this for current Beta (allowable range with >2.0.0-beta as value)

Is there a reason FF, et. al, in main is not using more normal semver specifiers like the archives branch instead of pinned?

fast/packages/web-components/fast-foundation/package.json

Line 98 in c64110d

"@microsoft/fast-element": "^1.12.0",

Is it an artifact of the prerelease tags that goes away in release?

This is likely just an artifact of publishing.

@rajsite agreed on this comment around common usage. Out of curiosity, what monorepo solution are you all using? I know that some have options to prevent hoisting certain packages where there are deltas. I'd like to dig in more if there is a concern this will cause headaches broadly. My guess is that "generally" it's beneficial, but folks hosting disparate versions may need to signal to not hoist different major versions and would want to be sure the major players account for that.

[bheston]

I'm not aware of any other fast foundation-like libraries being shared in the community (though we would like to make one soon with menu-button, date-picker, and a few more not in fast-foundation yet).

We should get those into fast-foundation! I was planning to take over the abandoned date picker once I was done with the other foundation updates I have in queue. Would love to see more contributions to flesh out the offering.