[ocavue]

Summary

Commit the generated *.prebuilt.ts / *.prebuilt-dev.ts files to git, and exclude them from Biome (as a formatter).

Why

These files are produced by the prebuild step but imported as normal TS modules. Keeping them in .gitignore caused two issues:

1. CI flakiness. Turbo caches the build step. On a cache hit the prebuilt files are not written to disk, so later steps that import them fail. Seen twice recently; passes on retrigger.
2. Fresh-clone friction. After pnpm install, pnpm typecheck fails until pnpm build runs.

The files are small, rarely change, and carry a "do not edit, regenerate via prebuild" header.

Alternative

Declare the files as outputs in turbo.json. Rejected because:

1. Does not fix the fresh-clone case.
2. Committing the files is simpler to understand and maintain than a Turbo-specific config, which is easy to break later (e.g. when the file structure is refactored).

Testing

CI should pass.

(I guess the workflow job "Bundled size" failed only because this PR is from a fork)

Docs

The comment at the top of these generated files is already clear enough.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 55eec6d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[codspeed]

Merging this PR will not alter performance

✅ 18 untouched benchmarks

---

_{Comparing ocavue-forks:ocavue/inline-prebuilt (55eec6d) with main (1d0bd55)¹}

Footnotes

1. No successful run was found on main (18879c3) during the generation of this report, so 1d0bd55 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[ematipico]

@Princesseuh and @matthewp you might know better than me how/why the source code of the directives it is what it is. Would love your input

[matthewp]

I don't really think we should. I don't love the prebuild system and would love to find a replacement, but I don't think the friction of needing to run pnpm run build is really enough to justify adding build artifacts to the git history. I'd rather find another way, like having the built files be processed by Vite as normal JS that then gets inlined by the framework.

[ocavue]

I'd rather find another way, like having the built files be processed by Vite as normal JS that then gets inlined by the framework.

I will try this direction

[delucis]

Going to close this as consensus seems to be that another approach is needed. Thanks for the exploration @ocavue!