Upgrade to Ignite version 28.0.0

[toschdev]

Step-by-Step Upgrade Guide

There should be no major issue following the tutorial with v28.0.0 of Ignite, using Cosmos SDK v0.50.1

1. Install the Correct Version
   First, update your Ignite CLI to version 28.0.0 using the following command:

curl https://get.ignite.com/[email protected] | bash

2. Scaffold Chain Command Update
   The scaffold chain command has been updated. Replace:

ignite scaffold chain github.com/alice/checkers

with

ignite scaffold chain checkers

3. Docker Version upgrades
   Upgrade the Ignite version for the docker container accordingly.

4. Change in Module Path
   The path for module.go has changed to: x/checkers/module/module.go

5. Frontend Scaffolding Options
   Frontend Scaffolding is no longer default to Vue. Now, you can choose between Vue, React, Go or TypeScript

Use these commands:

ignite scaffold react
ignite scaffold vue

6. Update Scaffold Message for CreatePost Command
   Make sure to update the output for the scaffolded createPost command

7. AutoCLI Path Change
   The file x/checkers/client/cli/tx_create_post.go is now integrated with AutoCLI at x/checkers/module/autocli.go

8. Adjustment in Stored Game
   Update the store stored_game.go as follows:

storeAdapter := runtime.KVStoreAdapter(k.storeService.OpenKVStore(ctx))
store := prefix.NewStore(storeAdapter, types.KeyPrefix(types.StoredGameKeyPrefix))

9. Not sure if The "Adjustment" in chapter Store Object is necessary.

10. Chain-ID Requirements in CLI tx commands
    CLI transaction commands require a chain-id flag now. For example:

checkersd tx checkers create-game $alice $bob --chain-id checkers

Potential Issues and Resolutions

Dependency Conflicts: Ensure all dependencies are compatible with v28.0.0. Conflicts may arise due to the upgrade.
Docker Image Compatibility: Verify that the Docker image version aligns with the CLI version to avoid compatibility issues.
Frontend Scaffolding: If using a frontend framework, ensure it's correctly scaffolded as per the new commands. Old projects may need manual adjustments.
AutoCLI Integration: Check for any discrepancies caused by the new AutoCLI integration path and adjust your code accordingly.

Would appreciate your feedback on the upgrade

For more insights, it's valuable to check how tutorials have been upgraded within Ignite docs.
Checkout the amazing PR by @jeronimoalbi https://github.com/ignite/cli/pull/3705/files

[xavierlepretre]

Thank you.

1. If I scaffold the frontend into Typescript, does it use Telescope or protoc?
2. I am thinking of renaming the whole chain checkers-app and the module checkers to offer a clearer distinction to the learner. Any advice as to the naming convention and the - character?

About the content's other parts:

1. Does Ignite prepare the ground to edit inside EndBlock or whatever replaces it in ABCI++?
2. Anything changed with regards to transient store?
3. Does the new Ignite provide any assistance when scaffolding hooks?
4. Does the new Ignite facilitate setting up migrations?

[toschdev]

Hello Xavier,

1. Its a combination of protoc with ts-proto, protoc with openapiv2 and the swagger-typescript-api package
   Learn more about setting up the TypeScript frontend
2. The - char is fine to use. I'd recommend then scaffold the chain first without module, then add the checkers module:

ignite scaffold chain checkers-app --no-module && cd checkers-app
ignite scaffold module checkers

About the content's other part

1. Yes, using EndBlock is a good strategy
2. Ignite now uses the kv store service store.KVStoreService, in line with SDK v0.50
3. There is no scaffolding hook command.
4. No, but that would be a very good feature to add. We should create an issue for that

[xavierlepretre]

I am adding ideas to handle in the upgraded content.

1. Use --address-prefix checkers when scaffolding the chain. Unless you think of a better prefix.
2. The first ignite chain serve without custom module. Relevant actions to look around what is available?
3. What are the advantages of using app_config.go as opposed to app.yaml?

Initial suggestions and questions to Ignite:

1. In generate ts-client, force all npm versions without ^.
2. Are the generated files not duplicates of what could be found in cosmjs-types?
3. In ts-client, have an initially populated .env.
4. In ts-client, there are a lot of duplicates, for instance pagination.ts.
5. In ts-client, perhaps the folders like cosmos.auth.v1beta1 could be kept inside a generated folder to clean up the look.
6. Re-running ts-client modifies the generated files so much as to make it difficult to know what really changed the second time it was run. This is visible when you use Git for the diff.
7. Perhaps scaffold react is not ready? I get Failed to resolve import "../hooks/useClient" from "src/def-hooks/useAddress.ts"
8. Can I add the IBC functionality to my module after scaffolding?
9. If I have react folder as a git submodule, I cannot scaffold a module: Open .../tmp-checkers-app/react/.git: is a directory.
10. After adding my checkers module, I cannot really make it a submodule because the proto folder is not with it but instead is in the checkers-app. It would have been nice for it to be self-contained. Same remark about the api folder. Compare this to chain-minimal.
11. If I add a bank dependency when creating my module, it would be good that it scaffolds the mocked expected keeper (perhaps adding a make target), and populates it in testutil's keeper too instead of setting it to nil. For instance.
12. I want to store games to storage without their id. For that I am thinking of using composed objects, a bit like that. Would there be a best practice with Ignite that minimises manual work? My concern is also about how to go with GetAllStoredGame. What I did by hand.