Primary question: Does this boilerplate's layout — npm frontend workspace plus root pytest config — match how you want to structure a GenLayer project?
RepoDaily adoption score
RepoDaily rates this as 86/100 (strong) for adoption: evidence, installation path, production risk, differentiation, license clarity, and AI/agent fit are scored from the article sources and adoption notes.
4 source(s) across 3 source category/categories, plus a RepoDaily-specific evidence module when available.
5 workflow step(s), 5 next-action step(s), and 3 command/install signal(s) were detected.
Trending momentum is +543 stars, with maintenance/release/issue signals counted when present.
Risk is marked medium, with 4 security note(s) and 3 explicit skip condition(s).
3 opportunity lens item(s), 4 alternative(s), and 3 type-specific section(s) support differentiation.
License source or license wording is present.
1 AI/agent-related signal(s) were detected in the article text and metadata.
Project overview
genlayerlabs/genlayer-project-boilerplate is a starter template for building on GenLayer, the YeagerAI-linked contract platform targeted by the repository's own tooling: the `genlayer` CLI invoked by the deploy script and GenLayer Studio named in the test configuration. YeagerAI holds the 2024 copyright on the project's MIT license. The repository pulled 543 stars during the trend window and ranks ninth, which is notable precisely because its description, homepage, and topic fields are all empty — the stars are moving without any metadata help.
The root package.json is small enough to read in one sitting. The package is named genlayer-project, marked private, declared as an ES module ("type": "module"), and declares a single workspace: frontend. Four of the five scripts — dev, build, start, and lint — are one-line proxies that run `cd frontend && npm run <script>`. The fifth, deploy, is the outlier: it invokes `genlayer deploy` directly, with no cd, making deployment the only root-level concern that is not delegated downward. The lone devDependency is genlayer-js at ^1.1.8, which anchors the entire template to one point in the client library's release history.
The Python side is equally terse. A root pyproject.toml contains nothing but pytest configuration: testpaths is set to ["tests"], and a single marker named integration is documented as "tests requiring GenLayer Studio (run with gltest)". That one line is the most operationally meaningful sentence in the repository — it tells you the integration suite will not execute unless GenLayer Studio, the environment gltest drives, is available on your machine.
In short, this is a layout decision shipped as code. It does not hand you components, a styling system, or a tutorial; it hands you three pre-made choices: where the frontend lives, how deployment is invoked, and how Studio-dependent tests are labeled. For developers already committed to GenLayer, that settles most of the scaffolding argument on day one.
Why it is trending now
- 543 stars in the trend window at rank 9 — strong traction for a boilerplate whose description, homepage, and topics fields are all empty.
- Every root-level convenience funnels into GenLayer tooling: the deploy script runs `genlayer deploy`, and the sole devDependency is genlayer-js ^1.1.8.
- MIT licensing under YeagerAI's 2024 copyright removes permission friction for forks, internal use, and commercial derivatives.
- The template encodes a two-language convention — TypeScript frontend workspace plus root-level pytest config — that would otherwise be a from-scratch decision for every new project.
Problem it solves
- A new GenLayer project needs a frontend, a deploy path, and a test strategy; the template fixes all three positions before your first commit.
- Without the root proxy scripts, every dev, build, start, or lint command would require manually cd-ing into the frontend workspace.
- Integration tests hard-require GenLayer Studio; without a named pytest marker, Studio-less environments fail in confusing ways instead of being identifiable up front.
- Mixing a TypeScript app with Python contract tests raises a "where does configuration live" question; this repository answers it by putting pytest config at the root, next to package.json.
How it works
- Clone the repository; the root package.json declares workspaces: ["frontend"], "type": "module", and "private": true.
- Run any root dev, build, start, or lint script — each executes `cd frontend && npm run <same name>`.
- Note the deploy exception: `npm run deploy` invokes `genlayer deploy` at the root, backed by the genlayer-js ^1.1.8 devDependency.
- Run the Python tests: pyproject.toml points pytest at the tests directory via testpaths = ["tests"].
- Run integration tests with gltest; the integration marker's own documentation states these tests require GenLayer Studio.
Command surface: what the root scripts actually run
- `npm run dev`, `npm run build`, `npm run start`, and `npm run lint` all follow the same pattern: `cd frontend && npm run <script>`.
- `npm run deploy` is the only non-delegating script — it runs `genlayer deploy` directly from the repository root.
- The only declared dependency anywhere in the root manifest is genlayer-js ^1.1.8, listed under devDependencies.
- The test entry point lives in pyproject.toml: testpaths = ["tests"], with one marker, `integration`, documented as "tests requiring GenLayer Studio (run with gltest)".
- package.json sets "private": true — the template is meant to be forked, not published to npm.
Repository anatomy: one workspace, two languages
The repository is a minimal monorepo. npm workspaces is configured with exactly one member, frontend, which is also where the TypeScript language tag comes from. The root package.json adds "type": "module", so any root-level JavaScript is expected to be ES modules.
Deployment is treated differently from everything else: while dev, build, start, and lint belong to the frontend, `genlayer deploy` runs at the project root. That single asymmetry tells you the template authors consider deployment a whole-project concern and the frontend loop a workspace concern.
The Python half of the repository is represented in the source pack only by configuration: a root pyproject.toml whose sole content is [tool.pytest.ini_options]. There are no packaging metadata, dependencies, or build settings — just where tests live and how the integration marker is defined.
Maintenance risk: thin metadata and a young pin
- Repository metadata carries no description, homepage, or topics — discovery depends entirely on the genlayerlabs org name and word of mouth.
- No README content and no release or changelog entries appear in the source pack; the only version signal anywhere is genlayer-js ^1.1.8.
- The source pack's raw file URLs resolve LICENSE from the `master` branch but package.json and pyproject.toml from `main` — a hint of a branch rename that left at least one path behind.
- With a single caret-pinned devDependency, template freshness rides on genlayer-js releases; there is no in-repo record of which template revision matches which client version.
Adoption checklist before you commit
- Confirm you want the two-root layout: an npm-driven frontend workspace plus Python test configuration at the repository root.
- Verify GenLayer Studio is installable in your environment before relying on integration tests; the pytest marker definition is the only place this requirement is stated.
- Open frontend's own package.json and record which framework and scripts it declares — the source pack does not say what is inside the workspace.
- Accept that documentation lives outside this repo: with an empty description and no README in the pack, onboarding depends on GenLayer's own materials.
- Treat "private": true as a signal: this is a template to fork, not a library to depend on from other packages.
Who should pay attention?
Good fit if
- Starting a fresh GenLayer project and wanting `genlayer deploy` wired up on day one.
- Anyone who wants pytest conventions for Studio-gated integration tests predeclared in pyproject.toml rather than invented per project.
- Prototype-paced work where an MIT-licensed scaffold with the layout already argued beats a blank repository.
Skip for now if
- Projects not targeting GenLayer — the only root script that does anything beyond the frontend is `genlayer deploy`.
- Anyone who needs in-repo documentation: description, homepage, and topics are empty and no README ships in the source pack.
- Anyone expecting a UI framework or component kit; this template standardizes layout and commands, not interface code.
Risks and cautions
The scaffold is simple and MIT-licensed, but repository documentation is minimal, the whole toolchain hangs on genlayer-js ^1.1.8, and integration tests cannot run without GenLayer Studio.
- No README, description, homepage, or topics appear in the repository metadata from the source pack.
- Default-branch inconsistency: LICENSE resolves from master while package.json and pyproject.toml resolve from main.
- The integration marker's own definition states these tests require GenLayer Studio, adding an environment prerequisite nothing else documents.
- A single caret-pinned devDependency (genlayer-js ^1.1.8) means upgrade cadence is controlled outside this repository.
- MIT License, Copyright (c) 2024 YeagerAI — permissive terms that allow commercial use with notice retention.
- package.json sets "private": true, so the template is not intended for npm publication.
- No audit reports, security policy, or lockfile appear in the source pack; review the frontend workspace code before connecting wallets, keys, or funds.
- The deploy path invokes the `genlayer` CLI; treat any account or credential setup around deployment as sensitive even though the template itself ships no secrets.
Alternatives to compare
| Approach | When to use | Trade-off |
|---|---|---|
Hardhat | You are targeting EVM/Solidity chains rather than GenLayer and want a mature development environment. | Free, open source |
Foundry | You want a fast, Rust-based Solidity toolchain with tests written in Solidity. | Free, open source |
Truffle | You want a long-established EVM suite with official project scaffolds. | Free, open source |
Empty repository plus the genlayer CLI | You only need `genlayer deploy` and prefer to choose your own frontend and test layout. | Free |
What this trend reveals
Document the GenLayer Studio setup path
The pytest marker says integration tests require GenLayer Studio and run with gltest, but the pack contains no setup guide. A short README section on installing Studio and invoking gltest would remove the most likely first failure a forker hits.
Clone the repo, run pytest against testpaths = ["tests"] on a machine without Studio, and record the exact failure point that documentation would need to cover.
Flatten the script duplication
Four root scripts repeat `cd frontend && npm run ...`. npm workspaces can address a workspace directly, so the wrappers could shrink or be replaced with root-level additions such as a combined test-and-deploy check.
Compare `npm run dev --workspace frontend` behavior against the cd-based scripts defined in package.json.
Publish a versioned template trail
The only version signal in the repository is genlayer-js ^1.1.8. Tagging template revisions and noting which genlayer-js release each tag matches would tell forkers what changed without making them diff the tree.
Check the repository's tags and releases; the source pack lists none, so a changelog can start at the current ^1.1.8 pin.
RepoDaily verdict
A deliberately thin, MIT-licensed scaffold: it standardizes where the frontend lives, how deployment is invoked (`genlayer deploy`), and how Studio-dependent tests are marked. High value if you are already committed to GenLayer; thin if you need documentation, components, or anything beyond layout and commands.