Right now faculty-service.ts and major-service.ts use any as the return type on several HTTP methods, because we didn't have confirmed backend response shapes when they were written. To avoid blocking the pipeline over this, no-explicit-any is set to "warn" instead of "error" in eslint.config.js for now.
The backend facade migrations are still in progress (more classes than just Faculty and Major are getting migrated), so once those land we'll finally know the real shape of the data coming back from each endpoint. At that point we should go back and properly type these instead of leaving any in place.
What needs to happen:
- Wait for the in-progress facade migrations to be merged
- Check the finalized response DTOs for the affected endpoints (create/edit/delete)
- Swap any for proper types/interfaces in faculty-service.ts, major-service.ts, and anywhere else this pattern shows up
- Flip @typescript-eslint/no-explicit-any back to "error" in eslint.config.js once everything's typed
Done when:
No more any in the service files
Lint rule is back to "error"
npm run lint comes back clean, 0 errors, 0 warnings
Right now faculty-service.ts and major-service.ts use any as the return type on several HTTP methods, because we didn't have confirmed backend response shapes when they were written. To avoid blocking the pipeline over this, no-explicit-any is set to "warn" instead of "error" in eslint.config.js for now.
The backend facade migrations are still in progress (more classes than just Faculty and Major are getting migrated), so once those land we'll finally know the real shape of the data coming back from each endpoint. At that point we should go back and properly type these instead of leaving any in place.
What needs to happen:
Done when:
No more any in the service files
Lint rule is back to "error"
npm run lint comes back clean, 0 errors, 0 warnings