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

Add explicit return types and parameter types to public service and gateway methods

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

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
backend, tooling

Research direction

Start in .eslintrc.js, lines 36-37, where explicit-module-boundary-types is set to off, and switch it to warn with the options the issue lists. Then annotate public methods in src/core/auth/ and the WebSocket gateways in src/dashboard/, using existing DTOs and entities. Done when the rule runs at warn, those public methods have explicit types, npx tsc --noEmit passes (CI gate in .github/workflows/build-check.yml:29), and the warning count is recorded.

Written by the indexing model from the issue text.

Description

intermediate refactor

Problem

.eslintrc.js disables both return-type rules:

'@typescript-eslint/explicit-function-return-type': 'off',     // line 36
'@typescript-eslint/explicit-module-boundary-types': 'off',    // line 37

The first is a defensible choice for internal helpers. The second is harder to justify: with noImplicitAny: false, a public method with no annotations has no type information at all — callers get any without an explicit any appearing in the code.

This is why the ~98 : any annotations are only the visible half; unannotated public methods are the larger, invisible set.

Why it matters

NestJS services are consumed through dependency injection, so the inferred type of a public method is the service's public contract. Without annotations, that contract is unverifiable and refactors are risky — a changed return shape compiles fine everywhere and fails at runtime in whichever consumer happened to depend on the old shape.

Suggested Direction

Enable only the boundary rule, not the internal one.

// keep this off - it is too noisy for private helpers
'@typescript-eslint/explicit-function-return-type': 'off',
// turn this on - it guards the module's public contract
'@typescript-eslint/explicit-module-boundary-types': ['warn', {
  allowExpressions: true,
  allowTypedFunctionExpressions: true,
  allowHigherOrderFunctions: true,
}],

Start with warn so you can measure the blast radius before committing to error.

Then annotate, in this order:

  1. src/core/auth/ — the public contract most depended upon
  2. src/blockchain/oracle/ — submission result shapes
  3. src/investment/portfolio/ — the analytics DTO shapes
  4. WebSocket gateways in src/dashboard/ — gateway event payloads are consumed by external dashboards, so those types are effectively a published contract

Existing DTOs and entities in src/ should cover most return types; avoid inventing new shapes.

Constraints

  • Annotating boundary methods will surface genuine implicit-any errors now that noImplicitAny is still off but inference is forced. Expect to fix a handful of real bugs — file those separately rather than papering over them.
  • Do not flip explicit-function-return-type on in the same PR; it will swamp the diff.
  • npx tsc --noEmit is the CI gate (.github/workflows/build-check.yml:29) and must stay green.

Acceptance Criteria

  • explicit-module-boundary-types is enabled at warn.
  • Public methods in src/core/auth/ and src/dashboard/ gateways have explicit return and parameter types.
  • No no-explicit-any suppressions were added to make the warnings go away.
  • The warning count is recorded so the reduction is measurable.
  • npx tsc --noEmit and npm test pass.
Dominant language
TypeScript
Stars
7
Forks
55
Avg merge
1d 17h
Merged PRs (30d)
5

Getting set up

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 SourceXXL/alian_structure-api

All issues in SourceXXL/alian_structure-api

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.