Fix build issue caused by misnamed test file - #830
Conversation
Presently, builds are broken because the utils_test.ts file in api/src/folder/controller imports a function from the utilities in the /api/test directory. As a result tsc gets confused regarding what the root folder of the API package is, causing it to output in an unexpected place. This causes the Dockerfile to be unable to find the index.js needed to start the API server. This commit fixes this problem by moving the utilities from utils_test.ts to the test files that rely on them. This causes some duplication, but 1. I don't see an elegant way to get tsc to ignore a controller-specific test utils file without vitest becoming convinced that there's a test file with no tests in it (which it sees as an error) 2. The utils in utils_test.ts were for loading an clearing fixture data. It is probably best not to reuse functions for this across test modules, because these are expensive operations in terms of time and reusing them encourages us to load more data than a particular module might need.
9c08598 to
91a2a3f
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #830 +/- ##
==========================================
- Coverage 98.48% 98.48% -0.01%
==========================================
Files 93 92 -1
Lines 2570 2566 -4
Branches 483 483
==========================================
- Hits 2531 2527 -4
Misses 39 39
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
This PR fixes a TypeScript build/rootDir issue in @stela/api by removing a misnamed helper file (utils_test.ts) under src/ that imported from the workspace test/ utilities, and by inlining the needed fixture/setup helpers into the specific *.test.ts files that use them.
Changes:
- Deleted
packages/api/src/folder/controller/utils_test.tsto prevent it from being treated as part of the package’s compiled source output. - Moved the
loadFixtures/clearDatabasehelpers into each affectedfoldercontroller test file and importedrunFixturesdirectly there. - Updated tests to no longer import helpers from
./utils_test.js.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| packages/api/src/folder/controller/utils_test.ts | Removed misnamed test utility module that was contributing to the build/rootDir confusion. |
| packages/api/src/folder/controller/patch_folder.test.ts | Inlined fixture loading + DB truncation helpers; removed import of utils_test. |
| packages/api/src/folder/controller/get_folders_page.test.ts | Inlined fixture loading + DB truncation helpers; removed import of utils_test. |
| packages/api/src/folder/controller/get_folder_share_links.test.ts | Inlined fixture loading + DB truncation helpers; removed import of utils_test. |
| packages/api/src/folder/controller/get_folder_legacy.test.ts | Inlined fixture loading + DB truncation helpers; removed import of utils_test. |
| packages/api/src/folder/controller/get_folder_children.test.ts | Inlined fixture loading + DB truncation helpers; removed import of utils_test. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Presently, builds are broken because the utils_test.ts file in
api/src/folder/controller imports a function from the
utilities in the /api/test directory. As a result tsc gets confused
regarding what the root folder of the API package is, causing it to
output in an unexpected place. This causes the Dockerfile to be unable
to find the index.js needed to start the API server. This commit fixes
this problem by moving the utilities from utils_test.ts to the test
files that rely on them. This causes some duplication, but
test utils file without vitest becoming convinced that there's a test
file with no tests in it (which it sees as an error)
It is probably best not to reuse functions for this across test
modules, because these are expensive operations in terms of time and
reusing them encourages us to load more data than a particular module
might need.