Skip to content

feat: allow --no-template option on init - #564

Merged
chadoh merged 1 commit into
mainfrom
feat/no-frontend-init-366
Jul 21, 2026
Merged

feat: allow --no-template option on init#564
chadoh merged 1 commit into
mainfrom
feat/no-frontend-init-366

Conversation

@zachfedor

Copy link
Copy Markdown
Contributor

Removes all JS-related files from repo during project instantiation, including any config files used by npm packages since they won't be installed. Also skips package manager choice since unneeded. Then sets client = false in environments.toml for all contracts.

Closes #366

Removes all JS-related files from repo during project instantiation,
including any config files used by npm packages since they won't be
installed. Also skips package manager choice since unneeded. Then sets
`client = false` in environments.toml for all contracts.
@zachfedor
zachfedor requested review from b4sen and chadoh July 15, 2026 22:05
Comment on lines +135 to +136
/// `client = false` on every contract in `environments.toml` so `build`/`watch`
/// never generate (or deploy for) client packages there is no app to consume.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if this is what @ElliotFriend had in mind.

Elliot: we are adding a --template none option to Stellar Scaffold, so you can quickly scaffold a contracts-only project. You originally requested this feature. (It was a long time ago, and I lost track of the conversation. Was it in Slack? Was it in GitHub? Was it in Discord?)

Why use scaffold for this situation? I can think of several benefits, vs hand-rolling:

  1. Toolchain consistency: quickstart, SDK version, CLI version, etc all wired together correctly
  2. Rust workspace setup
  3. Easy to add new OZ & soroban-examples contracts
  4. Smarter builds: stellar scaffold build resolves inter-contract dependencies and builds in the correct order
  5. Easy integrations: auto-generate TS bindings (aka NPM modules) for each of your contracts. Even if you're not using them in this project, generating them as-you-go enables you to easily ship them for your users or export them for use in other projects.

Do we care about Benefit 5? Do you care, @ElliotFriend?

If we do, then the functionality I'm commenting on here is wrong. We should not set client: false for each contract in environments.toml. We should keep creating clients.

Also, if we're going to skip creating clients, instead of setting client: false, we could remove environments.toml altogether (and/or remove --build-clients from the package.json scripts).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reminder: setting client: false in environments.toml is just providing the default base for a post-init project. The user can always change those values after the fact and create the bindings if they'd like.

Comment thread docs/site/docs/cli.md
- A frontend application using the [scaffold-stellar-frontend](https://github.com/stellar-scaffold/ui) template
- Configuration files for both contract and frontend development

With `--no-template` (or `--template none`), the frontend layer is omitted entirely: no `app/`, no JS workspaces, no dependency install. Every contract in `environments.toml` is written with `client = false`, so `stellar scaffold build` and `watch` skip client package generation. Flip a contract back to `client = true` if you later need TypeScript clients.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, setting client = false for all of them makes it easy to later set client = true, if someone wants that. Seems reasonable enough! What do you think, @ElliotFriend?

@chadoh chadoh left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good enough for now! We can get feedback and see how people want to use this.

@chadoh
chadoh merged commit 9f10821 into main Jul 21, 2026
10 checks passed
@chadoh
chadoh deleted the feat/no-frontend-init-366 branch July 21, 2026 19:23
@github-actions github-actions Bot mentioned this pull request Jul 21, 2026
chadoh added a commit that referenced this pull request Jul 23, 2026
## 🤖 New release

* `stellar-scaffold-cli`: 0.0.25 -> 0.0.26 (✓ API compatible changes)
* `stellar-scaffold-reporter`: 0.1.1 -> 0.1.2 (✓ API compatible changes)

<details><summary><i><b>Changelog</b></i></summary><p>

## `stellar-scaffold-cli`

<blockquote>

##
[0.0.26](stellar-scaffold-cli-v0.0.25...stellar-scaffold-cli-v0.0.26)
- 2026-07-21

### Added

- allow --no-template option on init
([#564](#564))
- optimize build
([#569](#569))
</blockquote>

## `stellar-scaffold-reporter`

<blockquote>

##
[0.1.2](stellar-scaffold-reporter-v0.1.1...stellar-scaffold-reporter-v0.1.2)
- 2026-07-21

### Other

- *(stellar-scaffold-reporter)* rm dupe changelog
([#563](#563))
</blockquote>


</p></details>

---
This PR was generated with
[release-plz](https://github.com/release-plz/release-plz/).

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Willem Wyndham <willem@ahalabs.dev>
Co-authored-by: Chad Ostrowski <221614+chadoh@users.noreply.github.com>
Co-authored-by: Willem Wyndham <willem@wyndham.tech>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Allow users to choose "No Frontend" when scaffolding a new project

2 participants