split gomockhandler.json into configuration file and mocks status file

sanposhiho / gomockhandler

Mr. gomockhandler is the clever and more agile manager of golang/mock (uber/mock) 👔

MIT License

105 stars 8 forks source link

split gomockhandler.json into configuration file and mocks status file #74

Open sanposhiho opened 2 years ago

sanposhiho commented 2 years ago

from #59

Let's move source_checksum and checksum from gomockhandler.json to new 'mocks status file'.

with this

we can make configuration file more readable
we can allow user to edit configuration file directly

riita10069 commented 2 years ago

Hi! @sanposhiho Does this Proposal maintain downward compatibility with existing projects?

sanposhiho commented 2 years ago

Maybe yes. I think we can achieve this without breaking existing projects. But it's possible we'll find out that we can't during developing this feature.

my plan: In order not to break existing projects, when we use mock status(= source_checksum and checksum) in each command,

basically, we check the new mocks status file and use mock status in it
and we also check source_checksum and checksum on gomockhandler.json
and if we find them on gomockhandler.json, we move them to the new mocks status file.
and then, delete them from gomockhandler.json.

This means that the gomockhandler.json is allowed to have source_checksum and checksum and they will be automatically moved to the new mocks status file. And when we release v2, we can delete source_checksum and checksum from gomockhandler.json.

wdyt?

riita10069 commented 2 years ago

I think we must consider some situations about Coexistence. if it fouund new mock status file, but gomockhandler.json has mock status too. Can it recognize the gomockhandler.json's mock status?

and if new mock status file and gomockhandler.json has different value of checksum as to same source. what should it behave?

A person who somehow upgraded its version will run a new command without realizing that the json file has been split.

sanposhiho commented 2 years ago

if new mock status file and gomockhandler.json has different value of checksum as to same source. what should it behave?

The checksum on new mock status file should take precedence. And the one on gomockhandler.json will be deleted at that time.

Basically, we should consider backward compatibility when we increment minor versions, but don't always need to forward compatibility including what happens when a project has both people using the old version and people using the new version.

Users on the same project should use the same version of tools ideally.

riita10069 commented 2 years ago

I understand. So it always works to converge to a newer version of json. Including existing files. Thanks for the reply.