Marve10s/Better-Fullstack: the generated config is still called bts.jsonc, the root manifest says 0.0.1 while the releases say 2.7.0, and one test script lists twelve files by hand

The generated project config is still named after the fork it came from

Every project this scaffolder writes records itself in two files, bts.jsonc and bts.lock.json, and the document credits that choice with letting add, update and check extend and repair a generated project later. The initials in those names are the interesting part. The license section states that Better Fullstack was originally forked from Better T Stack by Aman Varshney and is now independently maintained with its own direction. The upstream package was create-better-t-stack; the published package here is create-better-fullstack, so the registry name changed and the on-disk config filename did not. That is the kind of residue a fork accumulates quietly, and it is worth knowing about because bts.jsonc is not a private implementation detail. It is the file your project is written in, the thing an editor will open, and the thing a script that wants to inspect a generated project will have to hard-code. Two npm badges at the top of the document also point at the same package twice.

The root manifest says 0.0.1 while the release line is at 2.7.0

The root package.json carries version 0.0.1 and private set to true, which is the ordinary convention for a workspace root that is never published. The release history is a separate line. v2.7.0 went out on 2026-10-02, v2.6.8 on 2026-09-24 and v2.6.7 on 2026-09-15, so three releases inside seventeen days. The branch's last push is 2026-10-02, about ninety minutes after the v2.7.0 release, so the tree is effectively at that version. What is missing is any link between the two lines in the visible material. The root manifest that declares the workspaces for apps and packages holds nothing that tracks the 2.x numbering, and the release names are bare version strings with no description attached, so the release page tells you that 2.7.0 exists but not what changed in it. Changelog generation is configured, through a changelogithub.config.ts at the root, which suggests the history lives on the releases page rather than in a file in the repository. The cadence is regular enough to read as intentional: eight days between v2.6.8 and v2.7.0, ten days before that.

One compatibility engine, two different outcomes, and no rule for choosing

The strongest claim in the document is also the vaguest. The CLI and the browser builder share a single compatibility engine, and the stated consequence is that invalid combinations are rejected or adjusted before any file is written. Those are two different outcomes, and the sentence does not say which one you get. A rejection is safe, because nothing was created. An adjustment is the case that needs reading, because the project you receive may not be the one you selected in the builder. Nothing in the document describes whether the adjustment is reported, whether it can be overridden, or which combinations trigger which path. The repair story is better served: the description of bts.jsonc and bts.lock.json has add, update and check able to extend and repair what was generated earlier, which treats a scaffold as a starting point rather than a finished artifact. The test suite is built for that same claim, with dedicated files for scaffold upgrade, stack update and project transactions among the paths the lifecycle script enumerates.

Turbo drives most of the repo, then one script hand-chains four packages in order

The monorepo uses turbo for the ordinary work: turbo build, turbo dev, turbo lint and turbo test, with filtered variants for the CLI, the web app and the docs, and a turbo.json at the root. Then one script bypasses it entirely. build:core is a literal chain of four bun invocations that must succeed in order, covering packages/types, packages/project-lifecycle, packages/template-generator and apps/cli, each invoked with bun run and a directory switch. Two orchestrators means two build orders to keep straight, and the hand-written chain is the fragile one, since adding a package to the core means editing the string. The dependency is visible in how the CLI runs. The cli script does not go through turbo at all: it changes into apps/cli and executes node against dist/cli.js, which is compiled output. So a working CLI needs a successful build first, while dev:cli goes through turbo to run the unbuilt source. The repository is bun-native throughout, with bun.lock and bunfig.toml at the root and bun test used directly in the test scripts.

The lifecycle test script names twelve files and will not notice a thirteenth

Most of the test surface is delegated to turbo test, with filtered scripts for the CLI and the web app. Two are not. test:mcp builds the core first, runs the whole mcp directory, and then runs one file from that same directory a second time with an environment variable set, so the same test executes twice under two conditions. test:lifecycle is the sharper case. Instead of a directory it names twelve specific files in full: four under apps/cli/test/lifecycle, five under apps/cli/test/generation, two under apps/cli/test/mcp, two under apps/web/test/project and one under packages/template-generator. It also lists mcp-protocol.test.ts, which is already inside the directory test:mcp runs and which test:mcp then runs again explicitly. The cost of explicit lists is that they rot silently. A new lifecycle test is not picked up, and a renamed one fails as a missing path, but nothing in the repository enforces that the list is complete. A directory argument or a discovery pattern would have kept the same coverage without the manual bookkeeping. A third test script sits alongside the two, named test:mutation-contracts and pointed at a validation file under scripts/validation, which reads as a test of the checks themselves.

Four lint and hook layers, and three directories for coding agents

The root carries .oxlintrc.json for linting, .oxfmtrc.json for formatting, .lintstagedrc.mjs for staged-file checks and lefthook.yml for hooks, alongside AGENTS.md, CLAUDE.md and three agent-facing directories: .agents/, .claude-plugin/ and .codex/. That is four separate mechanisms covering the same ground, a lint rule, a formatter, a staged-file runner and a hook runner, plus a turbo lint task that fans the first one across the workspace. The agent integration is the more interesting half. A .claude-plugin/ directory and a .codex/ directory are two different distribution formats for agent tooling, and .agents/ is a third convention, all shipped in the same repository, which tells you the project intends to be driven by whichever assistant the user happens to run. The same intent shows up in the feature list, where supported agents scaffold projects through an MCP server. It is a scaffolder for humans and a scaffolder for tools, and both audiences get their configuration committed at the root. CONTRIBUTORS.md sits next to the agent files, and scripts/ holds the validation suite the mutation-contract test points into.

The badge row is dark-mode only and names two languages the description omits

The header is a row of images, and every one of them is written as a picture element with a single source guarded by a dark colour scheme media query. There is no light-mode source and no plain image fallback, so in a renderer that reports a light preference the entire row is empty, including the project logo. The same row also disagrees with the prose about what the project supports. The images are typescript, react, rust, go, python, java, dotnet and elixir. The repository description names five languages: TypeScript, Rust, Python, Go and Java. .NET, Elixir and React appear in the artwork and nowhere in the text, and the future stack section is a TypeScript-only story built on Solid, Effect and TanStack with oRPC, Drizzle, SQLite and Better Auth. So the first thing a reader sees and the sentence that describes the project do not cover the same set of things.

Four identical create commands, and one benchmark that is never defined

The quick start offers the same command four times, once per package manager, which covers the four ways a JavaScript project gets bootstrapped rather than four different things to try. A fifth command, npx create-better-fullstack@latest install, sets up the agent integration. The presetted path takes arguments of its own:

bun create better-fullstack@latest preset future-stack my-app
bun create better-fullstack@latest preset future-stack my-app --framework tanstack-start --effect server

That flag pair is the only place the document shows the shape of the choices, choosing between SolidStart and TanStack Start and deciding whether Effect runs inside the app or on its own server. The one performance figure in the whole document is in the agent section, which says supported agents scaffold projects through the MCP server 2.6x faster than hand-writing in ScaffBench. ScaffBench is not defined, not linked, and not described anywhere else in the visible text, so the comparison has no stated baseline. It is a striking contrast with the star history block lower in the same file, which is commented out with a full explanation of why, the GitHub stargazer API being restricted to admins and collaborators, plus a link to the cause and a note to restore it later. Badges get a documented reason. Benchmarks get none. The community row above it links an X account, a Telegram channel and a GitHub profile, none of which carries the Marve10s name used for the repository and its sponsor links, and sponsorship runs through GitHub Sponsors and Patreon.

Editorial conclusion

Better-Fullstack is worth a look if you want a starting stack rather than a blank directory, and the browser builder means you can see a configuration before committing to a runtime. Four things to check first. The compatibility engine is described with two verbs, invalid combinations are rejected or adjusted, and the document does not say which applies when, so read what the CLI reports rather than assuming your selection was honoured. The generated project's config file is named bts.jsonc, a leftover from the Better T Stack fork, and any tooling you write against bts.jsonc will be coupled to a file name the project has already outgrown. The repository runs both turbo and a hand-written four-step bun chain, so a partial build can leave packages out of step with each other. And the single performance figure, 2.6x faster in ScaffBench, has no methodology or definition of ScaffBench in the visible text. For anything long-lived, read bts.jsonc before you scaffold, pin your own dependency versions afterwards, and treat the generated lockfile as a starting point rather than a decision.

Frequently asked questions

Official sources

1. License: MIT
2. Marve10s/Better-Fullstack on GitHub
3. Project website
4. README
5. Releases