Contract Development Workflow Issues and Missing Documentation
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- shell, solidity
- Bereich
- build-system, developer-experience, documentation, testing
Rechercherichtung
Beginne mit der Prüfung von .devkit/contracts/Makefile, .devkit/scripts/build und .devkit/contracts/foundry.toml und vergleiche anschließend deren Targets mit dem Verzeichnis ./contracts/ und dem devkit avs build flow. Done sollte eine dokumentierte Einrichtung der Abhängigkeiten sowie einen praktikablen Build- und Testpfad umfassen, der benutzerdefinierte Contracts abdeckt und schnelleres Feedback bei der Kompilierung liefert.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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:
- Navigate to
.devkit/contracts/and useforge install <dependency> - Update remappings in
.devkit/contracts/foundry.tomlif needed
- Navigate to
- For Node.js-based dependencies:
- Create a
package.jsonfile in.devkit/contracts/ - Update remapping in
.devkit/contracts/foundry.toml - Manually modify the build command in
.devkit/scripts/buildto:cd .devkit/contracts && npm install && forge clean && forge build -- --include ../../contracts/**/*.sol >&2
- Create a
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 buildtakes significant time due to multiple build steps (binaries, contracts, etc.)- Calling the build command in the Makefile directly doesn't build contracts outside the
.devkitfolder - 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.
- Vorherrschende Sprache
- Go
- Sterne
- 28
- Forks
- 10
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
Die Einrichtungsdateien dieses Projekts haben wir noch nicht geprüft. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus Layr-Labs/devkit-cli
-
running `devkit avs create` in `paltform: linux (debian)` fails if `apt-utils` is not installedOffen
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 35/100
Layr-Labs/devkit-cli#300 ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 38/100
Layr-Labs/devkit-cli#237 ·
-
devkit avs call fails.Offen
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 35/100
Layr-Labs/devkit-cli#231 · 3 Kommentare · 1 Reaktion ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 42/100
Layr-Labs/devkit-cli#221 · 2 Kommentare ·
-
TaskRequest.PayloadOffen
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 25/100
Layr-Labs/devkit-cli#202 ·
Alle Issues in Layr-Labs/devkit-cli
Ähnliche Issues
-
[Docs] - Document minimum Terraform/OpenTofu version (>= 1.11) required by write-only argumentsOffen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 92/100
MagaluCloud/terraform-provider-mgc#323 ·
Maintainer antworten meist innerhalb von 11 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
rossoctl/context-guru#366 ·
Maintainer antworten meist innerhalb von 1 Tag
-
stage-fail
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
siyuan-note/bazaar#2293 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
piraeusdatastore/piraeus-operator#1070 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
Maintainer antworten meist innerhalb von 1 Tag