• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

D-Pow / MockRequests / 207 / 1
100%
master: 100%

Build:
Build:
LAST BUILD BRANCH: feature/support-origin-agnostic-slash-urls
DEFAULT BRANCH: master
Ran 10 May 2021 01:15AM UTC
Files 1
Run time 0s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

10 May 2021 12:54AM UTC coverage: 100.0%. Remained the same
207.1

push

travis-ci

D-Pow
Bug fix: Fix types.d.ts outputs for nested custom typedefs

I'm not exactly sure why, but it seems any type references to the custom `@typedef` entries that are nested inside other `@typedef` entries fail to be parsed correctly by typescript, and end up with `any` as the type instead. e.g. `MockResponseConfig.dynamicResponseModFn == any` and `DynamicResponseModFn.request == any`. Idk if it's the fact that the declarations are nested inside a module/namespace or what, but none of the my work-around attempts worked (extracting them out of the function scope, unmarking them as `@member`, unmarking everything as `@member`, and all sorts of various tsconfig.json config field changes).

This meant that they had to be extracted to a separate file. But even if that helped generate the right type for a nested field, it still removed the JSDoc from them (even if tsconfig.json had `removeComments: false` and`importsNotUsedAsValues: "preserve"`). This would make IDE autocompletion way less helpful than it could've been (e.g. we should definitely tell the user what default values are and what exactly the purpose of the fields are).

Thus, the only acceptable solution was to move them to their own typescript file so that both the nested types and JSDoc would both be accurate. Of course, this hides them from the tsconfig.src.json parsing (even if changing configs like `include`, `files`, `typeRoots`). Since triple slash references (like `/// <reference path="./types.ts" />`) are ignored in `compilerOptions.module != 'AMD|System'`, they have to be imported in the src file itself so that they're properly injected into the final output types.d.ts file.

Long story short, I need to not do this manually. So a future TODO: either add a `ts-loader`/config entry to webpack.config.js, or convert the entire codebase to typescript.

84 of 84 branches covered (100.0%)

Branch coverage included in aggregate %.

131 of 131 relevant lines covered (100.0%)

63.48 hits per line

Source Files on job 207.1
  • Tree
  • List 0
  • Changed 1
  • Source Changed 1
  • Coverage Changed 1
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Build 176
  • Travis Job 207.1
  • 3b67ceb9 on github
  • Prev Job for on feature/add-webpack-plugin (#206.1)
  • Next Job for on feature/add-webpack-plugin (#217.1)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc