Why do you want to contribute?
I'd like to contribute a focused fix for #4495, where a task that is statically imported by another task file can be attributed to the importing file in the dashboard.
I reviewed the current CLI indexing path across the esbuild bundle manifest, registerResources, and the core resource catalog. The report's root cause is still present: with code splitting enabled, a shared chunk can evaluate while an importing entry's file context is active, and later entry imports reuse the ESM module cache.
I also reviewed the closed attempt in #4504. Sorting bundle entries would only make the result deterministic; it would not reliably identify the defining source file. Before opening a PR, I plan to add a regression test that bundles two task entry files with splitting: true and proves that each task manifest points to its defining file, then implement the smallest source-grounded fix that passes that test.
I will keep the PR limited to #4495, open it as a draft, include the required patch changeset for the CLI, and run the repository's formatting, lint, knip, and relevant package tests/build before requesting review.
Prior contributions or relevant experience
I work with TypeScript/Node.js codebases and have been studying Trigger.dev's CLI bundling, indexing, and resource-catalog architecture specifically for this issue. GitHub: https://github.com/AbdulSamad94
Why do you want to contribute?
I'd like to contribute a focused fix for #4495, where a task that is statically imported by another task file can be attributed to the importing file in the dashboard.
I reviewed the current CLI indexing path across the esbuild bundle manifest,
registerResources, and the core resource catalog. The report's root cause is still present: with code splitting enabled, a shared chunk can evaluate while an importing entry's file context is active, and later entry imports reuse the ESM module cache.I also reviewed the closed attempt in #4504. Sorting bundle entries would only make the result deterministic; it would not reliably identify the defining source file. Before opening a PR, I plan to add a regression test that bundles two task entry files with
splitting: trueand proves that each task manifest points to its defining file, then implement the smallest source-grounded fix that passes that test.I will keep the PR limited to #4495, open it as a draft, include the required patch changeset for the CLI, and run the repository's formatting, lint, knip, and relevant package tests/build before requesting review.
Prior contributions or relevant experience
I work with TypeScript/Node.js codebases and have been studying Trigger.dev's CLI bundling, indexing, and resource-catalog architecture specifically for this issue. GitHub: https://github.com/AbdulSamad94