fix(webapp): db seed script#4137
Conversation
|
WalkthroughThe db:seed npm script in apps/webapp/package.json is updated to invoke seed.ts instead of seed.mts as the database seeding entrypoint. Changes
Related Issues: None provided. Related PRs: None provided. Suggested Labels: None Suggested Reviewers: None Poem: A rabbit hopped through package.json's field, / Swapped .mts for .ts, a small change revealed, / Seeds will now sprout from a different file, / A tiny hop, but done in style. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
## Summary Getting the CLI talking to a local instance meant the browser magic-link login, which is no good when you're driving things headlessly (an agent, a container, or just no browser to hand). The seed already prints dev secret keys for the batch-limit orgs, so it now also mints a personal access token for the seeded `local@trigger.dev` user and prints a ready-to-run `export TRIGGER_ACCESS_TOKEN=...` next to them. Re-seeding stays idempotent: it decrypts and reprints the existing `local-dev-cli` token rather than piling up a new one on every run. <!-- GitButler Footer Boundary Top --> --- This is **part 2 of 2 in a stack** made with GitButler: - <kbd> 2 </kbd> #4135 👈 - <kbd> 1 </kbd> #4137 <!-- GitButler Footer Boundary Bottom --> --------- Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Summary
pnpm run db:seedfailed withSyntaxError: The requested module './app/models/organization.server' does not provide an export named 'createOrganization', even though that export exists. Renaming the seed entrypoint from
seed.mtstoseed.tsruns it as CommonJS and fixes the failure.No seed logic changes.
Root cause
seed.mtsis an ES module, but the server modules it imports (.tsfiles, andno package declares
"type": "module") resolve as CommonJS. tsx compiles thoseto CommonJS using esbuild's getter-based export shape
(
Object.defineProperty(exports, name, { get })), which Node'scjs-module-lexerdoes not detect when it links the ESM importer. The namedexports look absent, so linking throws before any code runs.
The seed only ever needed the
.mtsextension: it has no top-levelawaitandno
import.meta. Running it as.tskeeps the whole import chain CommonJS toCommonJS and never crosses the lexer boundary. Verified the seed runs to
completion after the change.
Possibly caused by Node 22 upgrade?
This is part 1 of 2 in a stack made with GitButler: