Remove the dead `src/portfolio/` module — it is never imported and duplicates `src/investment/portfolio/`
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Refactor
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- nodejs, typescript
- Domain
- backend
Research direction
Start with src/portfolio/portfolio.module.ts, src/portfolio/controllers/portfolio.controller.ts and src/portfolio/services/rebalancing.service.ts, and confirm with a grep for src/portfolio/ that nothing outside the directory imports them. Diff the stub's rebalancing.service.ts against src/investment/portfolio/rebalancing.service.ts to check for unique logic, then remove the directory. Done when src/portfolio/ is gone, no references remain, and npx tsc --noEmit, npm test and npm run openapi:export show no changes.
Written by the indexing model from the issue text.
Description
Problem
src/portfolio/ is an orphaned copy of the portfolio feature. It contains:
src/portfolio/portfolio.module.ts(9 lines)src/portfolio/controllers/portfolio.controller.ts(34 lines)src/portfolio/services/rebalancing.service.ts(48 lines)
PortfolioModule is exported from src/portfolio/portfolio.module.ts, but it is never imported or registered anywhere. A repo-wide search for src/portfolio/ and PortfolioModule returns only:
src/app.module.ts:32 import { PortfolioModule } from "./investment/portfolio/portfolio.module";
src/app.module.ts:263 PortfolioModule,
src/dashboard.module.ts:4 import { PortfolioModule } from "src/investment/portfolio/portfolio.module";
src/portfolio/portfolio.module.ts:9 export class PortfolioModule {}
src/investment/portfolio/portfolio.module.ts:93 export class PortfolioModule {}
Both files export a class named PortfolioModule, and only the investment/ one is wired up. The real feature lives in src/investment/portfolio/, where portfolio.controller.ts is 434 lines and rebalancing.service.ts is 447 lines, versus the 34- and 48-line stubs here.
Why it matters
This is actively misleading. A contributor searching for "portfolio rebalancing" finds two implementations and has no way to tell that the short one is dead. tsc --noEmit passes because the files compile fine — they are just never instantiated, so nothing catches them. It is also a live footgun: the stub's PortfolioController is annotated @Controller("portfolio"), the same path prefix the real one uses. If someone ever registers it by mistake, the routes collide (see the separate route-collision issue).
There is precedent for this exact cleanup: issue #4 removed orphaned legacy services from src/auth/, and issue #5 flattened a nested directory.
Suggested Direction
Confirm the directory is genuinely unreferenced, then delete it:
- Re-run the verification:
grep -rn "src/portfolio/" src/should return nothing outside the directory itself. Also checktest/,scripts/, and thedocs/*.mdfiles for references. - Before deleting, diff the two
rebalancing.service.tsfiles to confirm the stub has no behaviour the real one lacks. At 48 versus 447 lines it is almost certainly a stub, but read it rather than assume — if it does contain unique logic, port that first. git rm -r src/portfolio/- Note the removal in
CHANGELOG.md.
The same shape of problem exists for src/profiling/ versus src/observability/ (both have a profiling.service.ts and a profiling.controller.ts) — see the separate issue on that.
Constraints
src/investment/portfolio/portfolio.module.tsmust stay untouched.- Verify
docs/openapi.jsondoes not change, or explain any difference — these controllers were never mounted, so they should not appear in the spec. - Use the
src/path-alias import style (enforced byimport/no-relative-parent-importsin.eslintrc.js) for any follow-up references.
Acceptance Criteria
-
src/portfolio/no longer exists. - No reference to
src/portfolio/remains insrc/,test/,scripts/, ordocs/. - Any unique logic from the stub
rebalancing.service.tshas been ported or explicitly noted as intentionally dropped. -
npx tsc --noEmitandnpm testpass. -
npm run openapi:exportproduces no schema changes.
- Dominant language
- TypeScript
- Stars
- 7
- Forks
- 55
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 5
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from SourceXXL/alian_structure-api
-
good first issue help wanted security
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SourceXXL/alian_structure-api#266 ·
-
Parallelize the cache-warming loop in `cache-warming.service.ts` — warmers run strictly sequentiallyPossibly taken @syntaxsuuvam-spec claimed this 3 days ago. Opengood first issue performance
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SourceXXL/alian_structure-api#240 ·
-
documentation help wanted intermediate refactor
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
SourceXXL/alian_structure-api#215 ·
-
good first issue refactor tooling
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
SourceXXL/alian_structure-api#199 ·
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SourceXXL/alian_structure-api#175 ·
All issues in SourceXXL/alian_structure-api
Similar issues
-
e2e-failure ready-to-code
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
redhat-developer/rhdh-plugin-export-overlays#4391 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
Luligu/matterbridge#655 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
software-mansion/argent#1457 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
schmayterling/hibi#245 ·
Maintainers usually reply within 1 day
-
ai-driven-qa bug claude Minor
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
linagora/twake-contacts-frontend#241 ·
Maintainers usually reply within 1 day