Don't rebuild proto files if nothing in the proto dir has changed

[fadeev]

Rebuilding proto files takes time, would be great if we could skip the process for when only Go files are changed.

[fedekunze]

ideally building proto files should be disabled and should only run by passing a flag. Otherwise starting the chain takes way longer than necessary

[fadeev]

We're adding a separate command that will generate go from proto: starport generate proto-go, so it can be run manually. Maybe adding starport chain serve --skip-proto makes sense. I would still keep make serve build everything by default, because it's what new developers want: build everything for me with a single command.

[ilgooz]

• Let's try to omit go mod download and check how much time we cut from there.

For proto:

• Calculate a hash from go.mod + proto files in the project, including third party ones defined in the config.yml + isRebuildAll enabled.
• And calculate a hash from the contents and paths of generated files.

If these two hashes are the same between c build executions or when c serve triggered by a file change, automatically skip generating code from proto for go and others enabled through the config.yml.

[ilgooz]

Our last decisions about this future:

• When a proto is changed under the proto/ dir of a chain; we'll check which module has changed and only do code generation for that module.
• When a proto file is changed in one of the third party dirs defined in config.yml: we'll do code generation for all of the modules of the chain (for entire proto/ dir of the chain).
• When the go.mod of the chain has changed; we'll do code generation for the modules imported in go.mod and for the entire proto/ dir of the chain.

also see #1997.

[ilgooz]

One more thing to add to this, we need to break the cache per module basis if the generated go files modified/deleted under x/ or when generated Dart/JS/Vuex code is modified/deleted for a module. cc @ivanovpetr

[ivanovpetr]

@ilgooz You mean we need to regenerate all proto outputs (*.pb.go, vuex, dart) if some of them was deleted/modified? And outputs also should be tracked for every module separately.

[ilgooz]

Yes but separately for *.pb.go, vuex, dart.

If *.pb.go changed for a module, we only re-generate *.pb.go for that module.
If vuex changed for a module, we only re-generate vuex for that module.
If dart changed for a module, we only re-generate dart for that module.

By mean changed, yes it means deleted or modified.

[ilgooz]

Hey @ivanovpetr we need to prioritize improvements for the network cmd so, I put this issue to hold and remove it from the board. If you already have some existent code for it, you can create a draft PR and link to the issue so we can revisit later.

[ilgooz]

closing in favor of #2383.

[ilgooz]

@fedekunze the latest release v0.22.1 now has an advanced caching system, works pretty fast now and it'll rebuild the modified proto packages (SDK modules) only.

You can observe the change in all Ignite CLI commands that requires to build from proto files, e.g.: chain serve/build/generate