Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Split shared domain types into focused modules

Open
  • Is something wrong?
#66 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Refactor
Clarity
Clearly specified
Activity status
Quiet
Tech stack
node.js, typescript
Domain
cli, developer-experience, tooling

Research direction

Start by inventorying every export in src/types.ts and grouping them by ownership (topics, reviews, assessments, sessions, memory, roadmap, storage, config, validation, CLI). Split into domain modules under src/types/ following real import boundaries, moving validation types with issue #25 where they belong. Update imports incrementally without compatibility wrappers or cycles, keep typecheck and tests green, and add a short note on the new layout for contributors. Done when unrelated subsystems no longer share one catch-all types file and public CLI behavior is unchanged.

Written by the indexing model from the issue text.

Description

core enhancement priority: low

Summary

src/types.ts currently contains types from many different domains: topics, assessments, reviews, sessions, memory, configuration, storage locks, caching, validation, dependency graphs, roadmap data, and CLI options.

This is convenient while the project is small, but it is becoming a broad dependency hub and will make the codebase harder to navigate and evolve as PALEE grows.

Problem

A change to one domain can require importing the same large shared module used by unrelated domains. It also makes it harder for contributors to answer simple questions such as "where are session types defined?" or "which types belong to storage?".

The issue is maintainability and dependency boundaries, not runtime correctness.

Proposed direction

Gradually split src/types.ts into domain-oriented modules, for example:

src/types/
  topic.ts
  review.ts
  assessment.ts
  session.ts
  memory.ts
  roadmap.ts
  storage.ts
  config.ts
  validation.ts
  cli.ts

The exact grouping should follow actual dependency boundaries rather than creating a file for every interface.

Scope

  • Inventory the current exports in src/types.ts.
  • Group types by ownership/domain.
  • Move validation-specific types into the validation module as part of #25 where appropriate.
  • Avoid unnecessary compatibility wrappers or circular imports.
  • Update imports incrementally.
  • Preserve runtime behavior and public CLI behavior.

Acceptance criteria

  • Domain types no longer require a single catch-all src/types.ts for unrelated subsystems.
  • Each resulting module has a clear ownership boundary.
  • No circular dependency is introduced.
  • Typecheck and tests remain green.
  • The final structure is documented briefly for contributors.

Priority

Low. This should be done opportunistically during related feature work rather than as a standalone rewrite.

Dominant language
TypeScript
Stars
1
Forks
0
Avg merge
21h 20m
Merged PRs (30d)
176

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Kuldeep2822k/cli

All issues in Kuldeep2822k/cli

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.