search

JamieMason / syncpack

Consistent dependency versions in large JavaScript Monorepos.
https://jamiemason.github.io/syncpack/
MIT License
1.34k stars 44 forks source link

question(core): should syncpack bump package versions after fixing mismatches? #188

Closed duytan-hoang-eurostar closed 6 months ago

duytan-hoang-eurostar commented 6 months ago

Description

After running fix-mismatches, should any modified packages have their version number updated with a patch? As the package has been updated

{
  "name": "my-package",
  "version": "1.0.0", // bump to 1.0.1
  ...
  "dependencies": {
    "react": "18.2.0" // updated from 18.1.0
  }
  ...
}

Suggested Solution

Not sure if there's a reason why this isn't the behaviour, but perhaps it could be an option? Would also be good if the option also allowed for the version to be formatted. Allowing things such as appending (e.g. 1.0.1-beta)

JamieMason commented 6 months ago

Thanks for the question Duytan.

I think this falls just slightly outside the scope of syncpack. It's not common to change lots of npm dependencies and then cut a release for publishing immediately, usually syncpack would be run as part of general housekeeping or linting then committed as a change on its own.

This would be tested and then other commits might accumulate such as features or bug fixes etc which are also tested, then once everything passes you would then cut a release – it's at that time that the version number of your own packages would tend to be bumped.

(The Syncpack project uses release-it for this by the way, which is excellent. There are other similar tools too.)

It's possible to create an npm script/build step/workflow/etc of your own which runs syncpack and cuts a release if anything changed, if that's what you wanted to do, but I don't think it is something that should be made part of syncpack itself.

The principle behind my thinking is that syncpack should focus on doing one thing well, then people can slot that in wherever they want to as one step of a bigger workflow.

Sound fair? Let me know what you think, thanks.

duytan-hoang-eurostar commented 6 months ago

Hi Jamie, thanks for getting to me. Yeah, I see your point. Was thinking it would've been nice to be able to piggy back off the looping that syncpack has already done. Or even better, are there any plans to provide an API so the output could be used?

I'll close this nonetheless. Thanks!

JamieMason commented 6 months ago

There is #48 which discusses a Node API, but FYI it's pretty much blocked at the moment, until I hear a good mix of use cases and when and how it would be used. I don't know what the requirements are for it so right now there's not a good justification for doing it. Plus the codebase of syncpack has been changing a lot as people have reported new feature requests or use cases etc. so I'd like it to have stabilised before having to support a Node API.