ignite / cli Goto Github PK

cover below:

• https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
• ...

Whenever a command is executed, check, whether it's the latest version. If not, display a notification.

For me, playing around with Starport for the Corporation prototype has meant a lot of tearing down and standing back up.

It would be very useful, if starport could:

• read a toml file that defines chain that I'm working on and then generate / serve the the needed code.
• save commands that trigger codegen (like the addition of types) to the TOML file so that the full feature state of a Starport chain is represented as TOML.

This toml file could also define addresses, so that those addresses are present on the chain between restarts.

Additionally, if this TOML file existed and were read by starport, I could create an automation system using kube-powered GitLab CI that allows users to interact with the chain as soon as their TOML file exists in a repository.

I will prototype this file and put it on this issue in a little bit. Basically, this TOML file should reduce the need to interact with starport using the CLI, and make CLI generated chains persistent.

...cwd (current working directory) with an optional flag like --path, -p. cc @fadeev

Node.js is useful to have installed for frontend development using the scaffolded app in ./frontend. If we include Node as a dependency in Homebrew it will provide better experience for developers, if they don't already have Node.

1-

Serving (executing long running binaries) and watching (files) for changes are pretty generic functionalities that are not specific to Starport itself.

I would like to suggest to extract these logic to a util package that maybe can be placed under a path called x/ or pkg/ and then use it in the serve cmd by wrapping with the logic specific to the Starport.

This way we can make a clear separation between the actual business logic of Starport and generic watch & serve functionality which should increase code readability by reducing code in the main business logic and reusability -of serve- in the long run.

2-

As a side effect of 1- the overall source code for serve functionality can be simplified on the way.

Developing cosmos sdk based applications requires constantly switching client library between testnets and binary versions. If there was a command that helps you switch cosmos environment faster like:

starport env cosmwasm-09

that switches the main chain/client binary versions and RPC, LCD endpoint variables, that would be really really cool.

Would be ideal, if starport app, starport app blog, starport app tendermint/blog, starport app github.com/tendermint/blog were all valid command invocations.

The first three will prompt the user for additional information.

$ starport app
Application name:

$ starport app
Application name: blog
Org or username:

$ starport app
Application name: blog
Org or username:

$ starport app
Application name: blog
Org or username: tendermint
Domain (default: github.com):

to display starport's version

Building the CLI on https://repl.it raises an error.

make: packr2: Command not found
Makefile:7: recipe for target 'build' failed
make: *** [build] Error 127

right now it is an empty page on npm https://www.npmjs.com/package/@tendermint/starport

we need to copy the readme.md at the root dir to .npm while running the related CI task.

Note: I tried starport without the UI

Overall I think the product is good. To me it feels like the scaffold tool with an additional serve functionality at this stage.
One thing that was lacking imo is better documentation and explanation in the CLI. After creating my app I was left without much info and I did not even know what happened (this may be fixed in the UI though).

Here are my comments:

• Is the default token of the starport app command the staking token of the chain? If yes this should be indicated. It would also be nice to add other features such as the ability to have custom prefixes for addresses (instead of the default "cosmos" prefix) or cointype as per BIP44 definition https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki (for ledger compatibilty). Also is there a way to set genesis params somewhere? (chain-id, number of validators, initial token supply, ...)
• starport add feature not documented - unclear what the command does
• not sure starport help is useful, given the --h flag exists
• would be nice to have a starport modules command, with the following subcommand
  • starport modules create [modulename] // creates a new module and adds it to the project
  • starport modules import [modulename] // imports an existing module (ibc, staking, ) from a module directory
  • starport modules list // lists all the modules used by the app, with a short description for each
• Right now starport works with a single custom created module folder right? I think it'd be interesting to let users create additional modules (as I described above), which means scaffold type would require a module field to know where to add the new type.
• I think it'd be great to identify a few major use cases and enhance starport type with it. Right now the type command is not super useful for things beyond trying out the SDK. I'm thinking about type "categories" like a "token" category where you would scaffold a specific token type with typical token functions such as "transfer" etc. It would make it easier to enhance the starport UI as well.

When scaffolding an application it would be nice to provide a simple github action setup. This does force users to use github but I don't see that as a large problem.

Just tried starport app github.com/your-github-id/name-with-dash and it installed with no problem but running starport serve resulted in an error that came from abci.go because the dash can't be used in package names. Would be good to have a name check before build to make sure the name is go friendly.

The root package contains all kinds of folders and files that does not directly related with the source code of Starport. I propose to collect the source code/packages of Starport under a special folder starport to create a clear separation. This makes it easier to understand the structure of source code.

I propose following:

root

.
├── (dot files)
├── go.mod
├── go.sum
├── LICENSE
├── Makefile
├── readme.md
├── scripts
└── starport

starport

├── interface
├── pkg
├── templates
├── services
└── ui

When building a new blockchain, developers would likely want to define new bech32 address prefixes for addresses and public keys like these: https://docs.cosmos.network/master/spec/addresses/bech32.html#hrp-table

The Cosmos SDK does seem to support customizing these prefixes, added in this PR by @cwgoes cosmos/cosmos-sdk#2614

Here is an example implementation of this change a SDK-based blockchain:
cybercongress/go-cyber@1026309

One thing I just thought of that is that this might break compatibility with wallets and other tools that only work with cosmos1 prefixed addresses. But that seems to be their problem, not ours.

Code generation is a tricky task. We make sure that Go and Vue app can build and serve and we're able to unlock wallet after each change we make to starport source code in order to test everything is fine.

This is a boring process and sometimes we may forget doing some of these checks. So I suggest to create a single e2e test that covers following steps:

• run make starport successfully.
• run starport app xxx successfully. - #146
• run starport type xxx successfully.
• run starport serve xxx successfully.
• go to starport technical page on a Headless Browser and check if user app is in the ready state.
• go to the user app page on a Headless Browser and unlock the wallet with mnemonic and check for 100 tokens.

BONUS:

• do all of them inside a Docker container.
• add a script at scripts/test-e2e to run this test.
• add a Github CI Workflow for it to run on each PR and merge to master.

cc @fadeev what do you think on this one?

Should we make a GIF from @fadeev's video on Youtube (but with a bit faster version) and add to the readme so developers can quickly understand what's up with Starport and can see how to create a Blockchain seconds. Also show the sample app on browser and unlock the wallet as it is on the video.

During today's call with @fadeev we debated about finding out the most effective, non error prone ways of source code manipulation that starport can do. Here are some early ideas came out from our call:

Problem

Starport is a tool to make it easier to build Tendermint apps specially for new comers. In order to do that, it creates a scaffold application with the app command. This is a very useful starting point and proven since there are other similar tools out there to do the same thing for other systems, fremeworks or libraries like a creating a scaffold for a Vue app.

But as I'm aware of these other tools only focuses on creating a scaffold once and after that point their job ends. It is, after that point developers' responsibility to take it from there and build their apps on top of it.

Starport differs at this point by also providing other functionality to continuously help developers to extend their apps at any point, even grown ones. But this is actually a hard thing to do. Because source code always evolves and developers may change the initial project structure, folder structure, file names, functions and other things and the generated code by starport. Thus, starport commands like type will not be able to function properly anymore.

Solution

In order to solve this problem, initially we saw two different solutions or combination of these two:

• Do not edit the source code after first creation of the scaffold with app command. When developers needs to add a new type with type command, we just print the type to stdout and encourage developer to put this code to the related(right) place in app's source code.
• Put some of the generated code to some separate files and add a "DO NOT EDIT" line on top of them so we can update these files as needed, as side effects of the usage of starport commands.

Notes

This proposal is meant to be a starting point to debate about this problem and find out all possible solutions. The idea is to make starport such tool that can be used to build any kind of Tendermint apps even if they are very complex ones or just a simple Hackathon projects.

when you generate a new type it comes with a keeper function to list all of them, in the user example it is listUser. This was initially confusing as it is actually listUsers. Very minor change but would make it more similar to Ruby on Rails commands that came with boilerplate get and set functions with attention paid to when it is plural and when it is not.

(still loving starport btw 😍)

If a user has git installed, initialize a repository, add all files and commit.

The Makefile has the dependency of npm this would be useful to know.

Starport code has accumulated a few golint errors that should be fixed 🙂

Currently, starport guides users through creating modules and customizing UI for them.

I propose that in the future, Starport should default to pure code generation married to pre-existing modules and UI components, and have the ability to generate modules using:

starport type sheet column1 column2 column3 column4 column5:bool

That's a 5-column spreadsheet right there. Then the developer can go and build any needed logic for it.

starport type sheet Name Address Account Hours:int LovesCheese

This repo doesn't seem to have a license file.

Do we need to re apply these lines that not related to starting a long running process after every change (watch) to the source code, or is it enough to do them once.

I'm brainstorming about some refactoring ideas, getting more details on this Q may help to my thinking process. 🛩️

• first make a initial version of cmdrunner pkg and use it to run short-living commands (the ones that does not start an http server) - #72
• use it for the http servers as well and add functionality to cmdrunner related to run long running commands and cancellation (killing the procceses). - #82
• stop calling make in serve and directly call commands inside make or migrate to Go code as needed (we can have Windows support thereafter!) - #110
• refactor FS watcher - #95
• simplify the overall refactoring made one more time
• some other improvements(PRs) also added referencing this issue, see them under this issue's timeline.

Thanks to your feedback for CosmJS. We have a bunch of improvements ready:

• First class launchpad support (support for 0.38/0.37 still exists but not heavily tested) in @cosmjs/launchpad (renamed from @cosmjs/sdk38)
• New SigningCosmosClient.signAndPost

The full list of changes between 0.21 and 0.22 is here: https://github.com/CosmWasm/cosmjs/blob/master/CHANGELOG.md. Version 0.22.0-alpha.0 now available on npm, which is feature-complete. The final 0.22.0 is expected within this week.

starport serve runs go mod tidy, initializes the chain and launches four servers: appd start, appcli rest-server, :8080 (frontend) and :12345 (welcome screen).

On exec, serve should check that the ports 26657, 1317, 8080, 12345 are available. If not, exit with an error telling what's wrong (ideally, print a kill command that will kill the process that is using the port).

Upon successful launch starport watches for file changes. If file change results in appd or appcli to exit, Starport should not exit, but print an error and wait for the next file change.

Starport should make sure to effectively kill all processes it starts, including node.

depends on #56

• I had to allow starport and blogd through my firewall I think
• every time I ran starport type xxx I had to allow blogd through the firewall again
• the block viewer is less useful in a small frame like this, it should be its own tab in Dev Tools
• ideally we can filter blocks by non-empty blocks so the block viewer isn't just filled with noise
• a navigation bar showing current block height and app name could be nice
• I'm very familiar with running multiple terminals for development, but it may feel a little clunky for developers to have to have three terminals open for development
  • one for starport serve
  • one for npm run serve
  • one to input starport commands

1. in GitLab CI:

https://gitlab.com/virgohardware/hardware/-/jobs/663817054

2. on my MacBook:

   Users/faddat/Library/Caches/node-gyp/14.6.0/include/node/v8.h:3673:37: note:
   candidate function not viable: requires 3 arguments, but 2 were provided
   V8_WARN_UNUSED_RESULT Maybe Set(Local context, uint32_t index,
   ^
   fatal error: too many errors emitted, stopping now [-ferror-limit=]
   4 warnings and 20 errors generated.
   make: *** [Release/obj.target/dns_sd_bindings/src/dns_sd.o] Error 1
   gyp ERR! build error
   gyp ERR! stack Error: make failed with exit code: 2
   gyp ERR! stack at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23)
   gyp ERR! stack at ChildProcess.emit (events.js:314:20)
   gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:276:12)
   gyp ERR! System Darwin 19.6.0
   gyp ERR! command "/usr/local/Cellar/node/14.6.0/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
   gyp ERR! cwd /usr/local/lib/node_modules/starport/node_modules/mdns
   gyp ERR! node -v v14.6.0
   gyp ERR! node-gyp -v v5.1.0
   gyp ERR! not ok
   npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/starport/node_modules/bufferutil):
   npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] install: node-gyp rebuild
   npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Exit status 1

   npm ERR! code ELIFECYCLE
   npm ERR! errno 1
   npm ERR! [email protected] install: node-gyp rebuild
   npm ERR! Exit status 1
   npm ERR!
   npm ERR! Failed at the [email protected] install script.
   npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

   npm ERR! A complete log of this run can be found in:
   npm ERR! /Users/faddat/.npm/_logs/2020-07-30T14_06_20_444Z-debug.log

currently starportcmd package resides to different business logic:

1. exposing Starport features as cli commands. e.g. A
2. imlementing Starport features. e.g. B and C.

I propose to extract part 2 for each cli command as a function or sub package to a new service package AKA controller.

So,

• we can have clear abstraction in between,
• increase test-ability,
• able to expose service (Starport) features via different interfaces in addition to cli commands as needed (maybe by X).

This is probably on the roadmap to release already, but just wanted to call it out that right now users to Starport are going to be a sub-optimal experience with the Homebrew release

Sometimes it panics, because too many open files. I wonder if we can include solution into the app itself or at least warn the user if the app panics because of this error.

https://hub.cosmos.network/master/validators/validator-setup.html#problem-2-my-gaiad-crashes-because-of-too-many-open-files

When demoing a starport chain / app, use of introspection tools like ngrok can be avoided by allowing starport serve to serve on 0.0.0.0 instead of just 127.0.0.1.

This would make showing off much easier.

MacOS 10.15

Hello while running the command "starport serve" I get the following error:

📦 Installing dependencies...
🚧 Building the application...
2020/07/27 18:55:28 Error in building the application. Please, check ./Makefile

Problem

Make does not come by default on Windows and sometimes on MacOS, Linux distros or other operating systems. Usually it needs to be installed separately or as a part of developer utility packages provided under the OS.

I suggest to drop the use of Make in order to:

1. reduce one more dependency that otherwise developers might be required to install manually,
2. simplify the overall source code logic of Starport.

Solution

We can run the commands that defined inside the template/Makefile in the Go program with the care of not using any OS specific commands to not break OS compatibilities.

Ideally, if there is a package/API for the command that needs to be executed, we can directly use it programatically.

Notes

This proposal only encapsulates the Makefile in the application template not the one that used to develop Starport itself.