filecoin-shipyard / js-lotus-client-schema Goto Github PK

• CLI tool that you run against the lotus directory
• Runs a go module using go reflection
• Outputs a JSON file

Not in scope:

• Ability to switch branches, etc.

We could set up CI pipelines to track development branches of Lotus and automatically
publish schema JSON files somewhere.

I think we should only check in schema files into this package for major branches.

For development branches, we could publish schema files and an index to IPFS and implement a schema loader to fetch a schema that matches a particular Lotus version (perhaps based on the git hash retrieved via the Version JSON-API method).

method MsigGetPending is not in the library. can we add this?

The command line tool should do the following:

1. Take in the directory with the Lotus source code as an argument
2. Generate a temp directory
3. Generate a go.mod file with a replace directive pointing to Lotus
4. Build/execute a go program in the temp directory that links to the Lotus libraries and uses go reflect to catalog the JSON-RPC methods, outputting a schema JSON file.

This tool should live outside the js-lotus-client-schema repo, but the generated outputs will be checked in here.

@marten-seemann we have 2 go packages in subdirectories this repo that we could get into the protocol/.github list. One catch is that we now have an auto-tag-and-release for each merged PR in this repo.

It’s not a big deal if we have patch releases triggered by the bot, but we could prevent them by including [ci skip] in the commit message.

We also use conventional-commits to build changelogs and determine semver bumps for each auto release, so it take the prefix: and use that to figure out patch/minor/major. Either like chore: or fix:, perhaps with a subsystem, chore(ci):, fix(ci): for descriptive changelog entries, would do the trick.

Do we have any flexibility in commit messages from the bot, or is that asking too much?

These packages are only for local codegen, not general consumption (at the moment anyway) so it's not a big deal if we leave them out because this is all too hard I think.

There is an issue importing the package. Problem is related to the CJS module, as it's exported as ES module.

Users/srdjan/js-poc/node_modules/@filecoin-shipyard/lotus-client-schema/mainnet/gen/index.cjs:461
export { CommonMethods, FullNodeMethods, StorageMinerMethods, GatewayMethods, WalletMethods, WorkerMethods }
^^^^^^

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Missing package.json file.

A package.json file at the root of your project is required to release on npm.

Please follow the npm guideline to create a valid package.json file.

Good luck with your project ✨

Your semantic-release bot 📦🚀