Static version property for component classes

[rickharris]

When writing component libraries that use spectrum web components that are used in a web app that also uses spectrum web components, it's easy to get into situations where versions conflict if all versions of components are not kept consistent. This is especially true for when a component has breaking changes.

Having a version available where you could do something like this:

const { version } = customElements.get('sp-action-bar') as SpectrumElement

This would help component libraries be able to make a decision about what to do. For example

1. If the registered component's version is semver compatible with the component libraries' dependency, there's no need to register the library's version of the component
2. If the registered component's version is not semver compatible the library might register and use the component using a custom tag name.
3. The component library could possibly smooth over backwards-incompatible changes by knowing what the registered version is and work around compatibility issues.

Scoped registries would also solve most or all of these problems, but that is a longer-term solution since no browsers currently have support for them. However having the version of a component could still be beneficial for component libraries when scoped registries are an option. By having the version available, a component library could see that an already-defined component is compatible and choose to not even load the component code if it's not necessary.

For the implementation, something like like genversion could be used to write the current version to a file before committing a new version. This will probably need to be a js file so that it doesn't need to be compiled, since typescript compilation will have already happened at that time.

An open question in my mind is, does writing a version file need to be done for each component individually, or can we write one version file in tools/base and set it on SpectrumElement so that each component inherits the version number. The latter could lead to unexpected results if different versions of components are mix-and-matched. For example if you used @spectrum-web-components/action-bar@0.35.0 with @spectrum-web-components/base@0.31.0, ActionBar.version would be "0.31.0". But it would probably be a simpler implementation if it's assumed that this will be a fairly niche feature, and that if someone used it we'd expect them to use uniform versions of components.

[benjamind]

I think we've standardized on one consistent version for all instances of SWC rather than mixing and matching across a version at least for now?

This has made version management a lot easier for apps, but of course does force users to update all components at once when new major versions occur. I personally don't think this is an issue and the benefits of not having to figure out what version of a component I need to install is a clear convenience win to me.

If that holds true for others too then I would guess a single version in the base class would be fine? Thoughts @Westbrook ?

[rickharris]

I spent a small amount of time coming up with a possible implementation for this, I can open a PR once we move this into an issue @benjamind @Westbrook https://github.com/adobe/spectrum-web-components/compare/main...rickharris:spectrum-web-components:static-version-property?expand=1

[Westbrook]

Seems like a decent start. Does it currently generate the version number somewhere? It seems out of date already, but maybe you've bound it to publish or something? That's always seemed the more complex part of this process.

[rickharris]

It does, yeah in the pre-commit hook. This was the only way I could figure out how to get it to write after the version had been updated but before the commit was made.

It's based off of main, I just haven't updated since I started toying with this last week.

[Westbrook]

This is now available as VERSION on the SpectrumElement base class.