Construct a build system #1

Keith-CY · 2022-10-08T10:00:54Z

Keith-CY · 2022-10-08T10:02:40Z

Are these features enough as a build system for the early stage? @homura @felicityin @yanguoyu

homura · 2022-10-09T06:13:45Z

These features I think are enough, but maybe run a ckb node could be launch a local node and network switcher, new developers could just rely on testnet, which would reduce the cost of setting up an environment such as an explorer etc.

Keith-CY · 2022-10-09T06:35:10Z

These features I think are enough, but maybe run a ckb node could be launch a local node and network switcher, new developers could just rely on testnet, which would reduce the cost of setting up an environment such as an explorer etc.

In hardhat, connecting to which network is specified by a --network option on starting, and all available networks are added in the configuration as

module.exports = {
  defaultNetwork: "rinkeby",
  networks: {
    hardhat: {
    },
    rinkeby: {
      url: "https://eth-rinkeby.alchemyapi.io/v2/123abc123abc123abc123abc123abcde",
      accounts: [privateKey1, privateKey2, ...]
    }
  }
}

https://hardhat.org/hardhat-runner/docs/config#available-config-options

I think specifying a network with a cli option is flexible enough, with that I can schedule tasks for various chains simultaneously. At least, it's good for CI as follows:

jobs:
  test:
    run: ... --network local
  prod:
    run: ... --network testnet

yanguoyu · 2022-10-09T07:18:02Z

Shall we need to add building, sign, and broadcast a transaction to the plugins? For developers to test the deployed contract on the chain. Or will it be in other packages?

felicityin · 2022-10-09T07:38:28Z

task/plugin system

deploy

What kind of contract to be deployed? Is it defined by Nervos or Kuai?

Keith-CY · 2022-10-09T07:41:13Z

task/plugin system

deploy

What kind of contract to be deployed? Is it defined by Nervos or Kuai?

A Contract model could have its source code, and contract.deploy should send a transaction to deploy it onto the chain, similar to the work in hardhat

async function main() {
  const [deployer] = await ethers.getSigners();

  console.log("Deploying contracts with the account:", deployer.address);

  console.log("Account balance:", (await deployer.getBalance()).toString());

  const Token = await ethers.getContractFactory("Token");
  const token = await Token.deploy();

  console.log("Token address:", token.address);
}

Keith-CY · 2022-10-09T07:43:51Z

Shall we need to add building, sign, and broadcast a transaction to the plugins? For developers to test the deployed contract on the chain. Or will it be in other packages?

I think supporting these functions via plugins will make the workflow uniform. BTW every plugin should be a package and necessary packages will be bundled and imported by default.

felicityin · 2022-10-09T07:48:35Z

task/plugin system

compile

Does a contract defined by Kuai need to be compiled? If yes, does a mockchain or vm need to be provided?

Keith-CY · 2022-10-09T07:56:53Z

task/plugin system

compile

Does a contract defined by Kuai need to be compiled? If yes, does a mockchain or vm need to be provided?

Sure, at this stage we will keep using Capsule for works of contracts but taking it over by JavaScript/TypeScript is one of our goals

Ref: https://github.com/ckb-js/topics/pull/5/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R374

A local node with flexible accessibility is desirable but out of our ability for now so we will start with a normal node.

Keith-CY · 2022-10-16T17:25:01Z

For me, the basic project structure could be like

.
├── .editorconfig              # general configuration for editors, https://editorconfig.org/
├── .env.example               # dotenv
├── .eslintrc                  # eslint configuration, https://eslint.org/
├── .git                       # git
├── .gitignore                 # gitignore
├── .prettierignore            # patterns to be ignored by prettier
├── .prettierrc                # prettier configuration, https://prettier.io/
├── README.md
├── _cache                     # cache artifacts of building for performance
├── build                      # built files and deployed info
├── dapps                      # dapp workspaces
│   └── dapp_1                 # a dapp, could be a front-end/backend/contract application
│       └── src
├── docs                       # docs to be deployed on GitHub
├── jest.config.ts             # tests configuration
├── kuai.json                  # project configuration
├── libs                       # lib workspaces
│   └── lib_1
│       └── src
├── node_modules
├── package.json
├── tools                      # tools for custom generators, plugins, tasks
│   ├── generators
│   ├── plugins
│   └── tasks
├── tsconfig.base.json
├── tsconfig.dev.json
└── tsconfig.prod.json

Keith-CY · 2022-10-17T04:10:51Z

The commands I'd like to have are as follows:

create-project: create the most basic project structure, with an interactive workflow to pick a generator for the very first dapp/lib. It could have the following options
- name
- generator: front-end, backend, contract, library
- git
generate: run a generator to create a dapp, the following generator are required
- front-end
- backend
- contract
- library
run: run a task to finish a specific work, like build, test, deploy, docs, version, publish, clean, format, node, etc.
run-many: run multiple tasks simultaneously
list: list dapps, libs, generators, tasks, and plugins
help: show the help message

Keith-CY · 2022-10-17T06:23:57Z

Tasks it may have

build: build front-end/backend applications or compile contracts
test
deploy: deploy the contract onto the chain
docs: generate docs
version: bump version
publish: publish to npm
clean: remove built artifacts and caches
format: check format or fix format
node: run a local ckb node

yanguoyu · 2022-10-17T08:05:41Z

For me, the basic project structure could be like

.
├── .editorconfig              # general configuration for editors, https://editorconfig.org/
├── .env.example               # dotenv
├── .eslintrc                  # eslint configuration, https://eslint.org/
├── .git                       # git
├── .gitignore                 # gitignore
├── .prettierignore            # patterns to be ignored by prettier
├── .prettierrc                # prettier configuration, https://prettier.io/
├── README.md
├── _cache                     # cache artifacts of building for performance
├── build                      # built files and deployed info
├── dapps                      # dapp workspaces
│   └── dapp_1                 # a dapp, could be a front-end/backend/contract application
│       └── src
├── docs                       # docs to be deployed on GitHub
├── jest.config.ts             # tests configuration
├── kuai.json                  # project configuration
├── libs                       # lib workspaces
│   └── lib_1
│       └── src
├── node_modules
├── package.json
├── tools                      # tools for custom generators, plugins, tasks
│   ├── generators
│   ├── plugins
│   └── tasks
├── tsconfig.base.json
├── tsconfig.dev.json
└── tsconfig.prod.json

Is the project structure for kuai?
Maybe we can rename _cache to .cache, most of time users will not care about it.
I feel confused why tsconfig is needed in different environments. And on the other hand, I think kuai.json may be in different environments.

yanguoyu · 2022-10-17T08:21:59Z

Some open-source projects may help us:

The complete solution for node.js command-line interfaces. https://github.com/tj/commander.js
A collection of common interactive command line user interfaces. https://github.com/SBoudrias/Inquirer.js
Better display for notifications in the terminal. https://github.com/chalk/chalk

Keith-CY · 2022-10-17T08:46:36Z

For me, the basic project structure could be like

.
├── .editorconfig              # general configuration for editors, https://editorconfig.org/
├── .env.example               # dotenv
├── .eslintrc                  # eslint configuration, https://eslint.org/
├── .git                       # git
├── .gitignore                 # gitignore
├── .prettierignore            # patterns to be ignored by prettier
├── .prettierrc                # prettier configuration, https://prettier.io/
├── README.md
├── _cache                     # cache artifacts of building for performance
├── build                      # built files and deployed info
├── dapps                      # dapp workspaces
│   └── dapp_1                 # a dapp, could be a front-end/backend/contract application
│       └── src
├── docs                       # docs to be deployed on GitHub
├── jest.config.ts             # tests configuration
├── kuai.json                  # project configuration
├── libs                       # lib workspaces
│   └── lib_1
│       └── src
├── node_modules
├── package.json
├── tools                      # tools for custom generators, plugins, tasks
│   ├── generators
│   ├── plugins
│   └── tasks
├── tsconfig.base.json
├── tsconfig.dev.json
└── tsconfig.prod.json

Is the project structure for kuai? Maybe we can rename _cache to .cache, most of time users will not care about it. I feel confused why tsconfig is needed in different environments. And on the other hand, I think kuai.json may be in different environments.

This is the project structure generated by kuai, just as we call create-react-app app_name and a new directory named app_name is created.

The directory for cache is named _cache instead of .cache because it's a temporary directory, a name starts with . just means an invisible path/file.

Individual tsconfig.json is not mandatory, but it would be kind for some cases. For example, the build for production doesn't need to cover tests

kuai.json is something like nx.json in nx system(https://nx.dev/reference/nx-json), or hardhat.config.js in hardhat(https://hardhat.org/hardhat-runner/docs/config#available-config-options), it's used as the common configuration of the project, like wallets, networks, dependency graph, path alias, etc.

Keith-CY · 2022-10-17T09:52:47Z

Some open-source projects may help us:

The complete solution for node.js command-line interfaces. https://github.com/tj/commander.js

A collection of common interactive command line user interfaces. https://github.com/SBoudrias/Inquirer.js

Better display for notifications in the terminal. https://github.com/chalk/chalk

There's another package to rule them all, https://github.com/google/zx, but I'm not saying it's good for every project.

PainterPuppets · 2022-10-18T01:27:45Z

Tasks it may have

build: build front-end/backend applications or compile contracts

test

deploy: deploy the contract onto the chain

docs: generate docs

version: bump version

publish: publish to npm

clean: remove built artifacts and caches

format: check format or fix format

node: run a local ckb node

This is a Design of node subcommand, the ckb node will started by docker

There will be a `kuai/docker' package to provide docker image's donwnload / run / cache etc...
like hardhat-docker or @electron/get

usecases might look like:

> kuai node run --port(option) xxx --config(option) xxx -d(option)

Started HTTP and WebSocket JSON-RPC server at http://127.0.0.1:xxxx/

Accounts
========

Account #0: ckt1qyqw8yx5hx6vwcm7eqren0d0v39wvfwdhy3q2807pp (20_000_000_000 CKB)
Private Key: 0xfd686a48908e8caf97723578bf85f746e1e1d8956cb132f6a2e92e7234a2a245

Account #1: ckt1qyqtdhd6s7a44a0s2wc6uk7tcl6duq68nalqvzxw09 (20_000_000_000 CKB)
Private Key: 0x5368b818f59570b5bc078a6a564f098a191dcb8938d95c413be5065fd6c42d32
...

Keith-CY added the enhancement New feature or request label Oct 8, 2022

Keith-CY assigned Keith-CY, homura, yanguoyu, IronLu233, PainterPuppets and felicityin Oct 14, 2022

Keith-CY modified the milestones: 2022/11/03 - 2022/11/10, 2022/12/08 - 2022/12/15 Oct 14, 2022

Keith-CY unassigned homura and IronLu233 Dec 8, 2022

Keith-CY assigned Daryl-L Dec 27, 2022

Keith-CY assigned zhengjianhui and unassigned felicityin Dec 27, 2022

PainterPuppets mentioned this issue Dec 28, 2022

Implement API service without business logic #89

Closed

Keith-CY mentioned this issue Mar 8, 2023

Support compile instruction in kuai-cli generated project #180

Closed

Keith-CY closed this as completed Jun 21, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Construct a build system #1

Construct a build system #1

Keith-CY commented Oct 8, 2022 •

edited

Loading

Keith-CY commented Oct 8, 2022

homura commented Oct 9, 2022

Keith-CY commented Oct 9, 2022

yanguoyu commented Oct 9, 2022

felicityin commented Oct 9, 2022

Keith-CY commented Oct 9, 2022 •

edited

Loading

Keith-CY commented Oct 9, 2022

felicityin commented Oct 9, 2022

Keith-CY commented Oct 9, 2022

Keith-CY commented Oct 16, 2022 •

edited

Loading

Keith-CY commented Oct 17, 2022 •

edited

Loading

Keith-CY commented Oct 17, 2022

yanguoyu commented Oct 17, 2022 •

edited

Loading

yanguoyu commented Oct 17, 2022

Keith-CY commented Oct 17, 2022

Keith-CY commented Oct 17, 2022

PainterPuppets commented Oct 18, 2022 •

edited

Loading

Construct a build system #1

Construct a build system #1

Comments

Keith-CY commented Oct 8, 2022 • edited Loading

Keith-CY commented Oct 8, 2022

homura commented Oct 9, 2022

Keith-CY commented Oct 9, 2022

yanguoyu commented Oct 9, 2022

felicityin commented Oct 9, 2022

Keith-CY commented Oct 9, 2022 • edited Loading

Keith-CY commented Oct 9, 2022

felicityin commented Oct 9, 2022

Keith-CY commented Oct 9, 2022

Keith-CY commented Oct 16, 2022 • edited Loading

Keith-CY commented Oct 17, 2022 • edited Loading

Keith-CY commented Oct 17, 2022

yanguoyu commented Oct 17, 2022 • edited Loading

yanguoyu commented Oct 17, 2022

Keith-CY commented Oct 17, 2022

Keith-CY commented Oct 17, 2022

PainterPuppets commented Oct 18, 2022 • edited Loading

Keith-CY commented Oct 8, 2022 •

edited

Loading

Keith-CY commented Oct 9, 2022 •

edited

Loading

Keith-CY commented Oct 16, 2022 •

edited

Loading

Keith-CY commented Oct 17, 2022 •

edited

Loading

yanguoyu commented Oct 17, 2022 •

edited

Loading

PainterPuppets commented Oct 18, 2022 •

edited

Loading