Hidden Assumptions in create-t3-app
12 assumptions this code never checks · 4 critical · spanning Environment, Ordering, Contract, Shape, Domain, Resource, Scale, Temporal
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at t3-oss/create-t3-app and picked out the few most likely to cause trouble. The full list is just below.
Most of what this code assumes is routine. These 3 are the ones most likely to cause trouble here. The rest are minor; they're under "Show everything".
If package manager is corrupted or returns non-version output, the packageManager field in package.json gets malformed data, potentially breaking future dependency operations
If createProject() fails partially or another process modifies files concurrently, fs.readJSONSync() could read corrupted JSON or the writeJSONSync() could overwrite unexpected changes
If any installer becomes async (e.g., downloading templates from remote), the createProject() orchestration will continue before files are written, leading to incomplete or missing configuration
Show everything (9 more)
The NextAuth() result has an 'auth' property that is a function suitable for React's cache() wrapper
If this fails: If NextAuth changes its API shape or auth is not a function, the cache() call fails at runtime with unclear errors in generated projects
cli/template/extras/src/server/auth/index.ts:cache
App names containing '@' follow npm scoped package naming conventions where the scope ends at the first '/' character
If this fails: Input like '@invalid@scope/app' or '@scope@version/app' gets incorrectly parsed, creating malformed directory structures or invalid package.json names
cli/src/utils/parseNameAndPath.js
The system has sufficient disk space, network connectivity, and npm registry access to install all accumulated dependencies from all selected installers
If this fails: Partial dependency installation leaves the generated project in an unusable state with no clean recovery mechanism - user must manually fix or regenerate
cli/src/helpers/installDependencies.js
Git is installed, accessible in PATH, and the target directory is not already inside a git repository or has conflicting git configuration
If this fails: Git initialization fails silently or creates nested repositories, but project generation continues, leaving users with unexpected version control setup
cli/src/helpers/git.js:initializeGit
The hardcoded default package selection ('nextAuth', 'prisma', 'tailwind', 'trpc', 'eslint') will always be valid entries in availablePackages array
If this fails: If availablePackages is refactored or package names change, buildPkgInstallerMap() receives invalid package names and generates incomplete installer maps
cli/src/cli/index.ts:defaultOptions
SidebarItem links follow the pattern `${TCode}/${string}` where TCode exactly matches a key in KNOWN_LANGUAGES
If this fails: Mismatched language codes in sidebar links create broken navigation - users clicking sidebar items get 404s or wrong language content
www/src/config.ts:SIDEBAR
The getVersion() function returns the current CLI version that remains stable throughout the project generation process
If this fails: If version detection fails or changes mid-generation, ct3aMetadata.initVersion gets incorrect data, making debugging and support harder
cli/src/index.ts:CT3APackageJSON
Every installer function expects the same InstallerOptions interface shape and uses only the properties relevant to their package
If this fails: Adding new properties to InstallerOptions or changing existing ones requires updating all installer implementations simultaneously or they break
cli/src/installers/index.ts:PkgInstallerMap
The deployment environment supports Astro's server output mode with Vercel adapter and can handle dynamic content rendering
If this fails: If deployed to static-only hosting, server-side features fail silently and users see incomplete or broken documentation pages
www/astro.config.mjs:output
See the full structural analysis of create-t3-app: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of t3-oss/create-t3-app →Frequently Asked Questions
What does create-t3-app assume that could break in production?
The one most likely to cause trouble: Package managers (npm, pnpm, yarn, bun) return version strings in stdout when called with '-v' flag and process execution will not hang or error If this fails, If package manager is corrupted or returns non-version output, the packageManager field in package.json gets malformed data, potentially breaking future dependency operations
How many hidden assumptions does create-t3-app have?
CodeSea found 12 assumptions create-t3-app relies on but never validates, 4 of them critical, spanning Environment, Ordering, Contract, Shape, Domain, Resource, Scale, Temporal. Most are routine — the analysis flags the two or three most likely to actually bite.
What is a hidden assumption?
Something the code depends on but never checks: a data shape, an ordering, an environment condition, a scale limit, or a contract with another service. It holds until the world it runs in changes, then fails silently.