Layr-Labs / Layr-Labs/devkit-cli

Contract Development Workflow Issues and Missing Documentation

Open
#217 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
27
Forks
10
PR merge metrics
No merged PRs in 30d

Description

Summary

While developing custom contracts with DevKit, I've encountered several workflow issues and gaps in documentation that make contract development more difficult than it should be. These issues primarily relate to dependency management, build processes, and the lack of fast feedback loops for contract compilation.

Issues Identified

1. Missing Documentation for Adding Contract Dependencies

Problem: When developers need to install libraries or packages for custom contracts, there's no clear documentation on how to properly add dependencies.

Current Workaround Required:

  • For Forge-based dependencies:
    1. Navigate to .devkit/contracts/ and use forge install <dependency>
    2. Update remappings in .devkit/contracts/foundry.toml if needed
  • For Node.js-based dependencies:
    1. Create a package.json file in .devkit/contracts/
    2. Update remapping in .devkit/contracts/foundry.toml
    3. Manually modify the build command in .devkit/scripts/build to:
      cd .devkit/contracts && npm install && forge clean && forge build -- --include ../../contracts/**/*.sol >&2
      

Impact: This creates a poor developer experience and requires deep knowledge of the DevKit internals.

2. Build and Test Process Doesn't Include Custom Contracts Directory

Problem: Both the build and test targets in .devkit/contracts/Makefile only work with contracts within the .devkit/contracts/ directory and don't include the main ./contracts/ directory where custom contracts are placed.

build:
    forge clean
    forge build

test:
    forge test -vvv

While there is a deploy-custom-contracts target that references custom contracts, the basic build and test commands don't validate that custom contracts compile correctly or run tests for them.

Impact:

  • Developers may write custom contracts in ./contracts/ that have compilation errors, but these errors won't be caught until deployment time
  • Custom contract tests placed in ./contracts/test/ won't be executed by the standard test command
  • No way to run targeted tests for custom contracts during development
3. No Fast Contract Compilation Feedback Loop

Problem: There's no quick way to verify contract compilation without running the full devkit avs build command, which includes many time-consuming steps beyond contract compilation.

Current Limitations:

  • devkit avs build takes significant time due to multiple build steps (binaries, contracts, etc.)
  • Calling the build command in the Makefile directly doesn't build contracts outside the .devkit folder
  • No dedicated contract-only build command for rapid iteration

Impact: Slow feedback loops significantly impact development productivity when iterating on contract code.

Additional Context

These issues became apparent while following the standard DevKit workflow for custom contract development. The current process requires significant manual intervention and deep knowledge of the build system internals, which may deter developers from effectively using DevKit for contract development.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by inspecting .devkit/contracts/Makefile, .devkit/scripts/build, and .devkit/contracts/foundry.toml, then compare their targets with the ./contracts/ directory and the devkit avs build flow. Done should include documented dependency setup plus a practical build and test path that covers custom contracts and provides faster compilation feedback.

Written by the indexing model from the issue text.

Assessment

Tech stack
shell, solidity
Domain
build-system, developer-experience, documentation, testing
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.