Check primer view components versions consistency on commit

[cbliard]

So that I'll stop upgrading it in Gemfile.lock and not in frontend/package.json. See #17681

[myabc]

@cbliard 👍🏻 definitely a good idea! - do you think this is best as a commit check or as a workflow check?*

• FWIW I'm (personally) not a big fan of commit hooks - I am constantly interactive rebasing, editing and squashing commits and when I've tried installing git commit hooks in the past, they really got in the way of my workflow. that said, everyone has a slightly different workflow, and setting up git hooks is an optional step for our team.

[myabc]

@cbliard this would obviously break if we were to do a minor release without the patch level component, e.g. 0.53. @HDinger do we always include the patch level (0) when we do major/minor releases?

[dombesz]

It would also not work with pre-release versions such as 1.2.3-alpha , however I'm not sure if we ever to pre releases.

[myabc]

We are currently publishing canary versions - see workflow here: https://github.com/opf/primer_view_components/actions/runs/12822373410/job/35755182385

🦋  info Publishing "@openproject/primer-view-components" at "0.0.0-20250117035659"
🦋  success packages published successfully:
🦋  @openproject/[email protected]

Whether or not we're actively using the canary versions while developing core features, I'm not sure (I've been working mostly linearly so far, so haven't had a need to do this yet).

@HDinger @bsatarnejad do you know? Do you always release primer-view-components before updating call sites in core (as I did with #17569).

[myabc]

As an aside: (this probably belongs in a wiki rather than PR comment)

the "escape hatch" for local dev is changing the dependency version in package.json to the local repo (e.g. "@openproject/primer-view-components": "file:../../primer_view_components"). Bundler does this better by letting you configure a local path override: bundle config local.openproject-primer_view_components=../../primer_view_components

[cbliard]

Yes, it follows semantic versioning.
And it won't break, it would just go unnoticed and print something like this:

Ok. Primer view components version is  everywhere

version is not detected

I could amend it slightly to make the message different if version can't be detected, but frankly that's overkill.

[HDinger]

@cbliard this would obviously break if we were to do a minor release without the patch level component, e.g. 0.53. @HDinger do we always include the patch level (0) when we do major/minor releases?

Yes, we do

[HDinger]

@HDinger @bsatarnejad do you know? Do you always release primer-view-components before updating call sites in core (as I did with #17569).

usually we do it like that, yes. I can imagine, that we want to try things with the canary versions locally but usually not in production.

[bsatarnejad]

Hi @myabc I always release Primer-view-components first, then update core with new version both in front-end and backend. Afterward, I make the necessary changes in the relevant places.

[cbliard]

I updated the script to include the pre-release version if any (the "pre.3-rt12" part in 1.2.3-pre.3-rt12 version), and also to have a better message if version cannot be detected.

[dombesz]

Works nicely, thanks @cbliard !

[cbliard]

👍🏻 definitely a good idea! - do you think this is best as a commit check or as a workflow check?*

Maybe a workflow check, but a commit check is cheaper and faster to develop. I just wanted to write one for me, and found it selfish to keep it private, hence this PR.

• FWIW I'm (personally) not a big fan of commit hooks - I am constantly interactive rebasing, editing and squashing commits and when I've tried installing git commit hooks in the past, they really got in the way of my workflow. that said, everyone has a slightly different workflow, and setting up git hooks is an optional step for our team.

Sure. That's why commit hooks are an option.
Lefthook is nice as it runs only if specified files have been changed, and it runs commands in parallel.

[cbliard]

Thanks for your suggestions @myabc. I pushed an updated version.
Could you review it again please?

[myabc]

Thanks for making the changes @cbliard!