rotating-file-stream: 1.3.8 Error calling function
Cannot invoke an expression whose type lacks a call signature. Type 'typeof import("C:/project/node_modules/rotating-file-stream/index")' has no compatible call signatures.
I think the definition file is wrong. I would also consider not using a default export.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 32 (23 by maintainers)
Commits related to this issue
- test fix for #29 — committed to iccicci/rotating-file-stream by iccicci 6 years ago
- test fix for #29 — committed to iccicci/rotating-file-stream by iccicci 6 years ago
- test fix for #29 — committed to iccicci/rotating-file-stream by iccicci 6 years ago
- Fix for issue #29 — committed to rakshith-ravi/rotating-file-stream by rakshith-ravi 6 years ago
- Fixed issue #29 (#30) * Added TypeScript Definition file * Fix for issue #29 — committed to iccicci/rotating-file-stream by rakshith-ravi 6 years ago
- Revert "Fixed issue #29 (#30)" This reverts commit 75cd3453ebd43384a7d473a9129f00ea913356f1. — committed to iccicci/rotating-file-stream by iccicci 6 years ago
- test fix for #29 — committed to iccicci/rotating-file-stream by iccicci 6 years ago
I don’t have a example with me, but as of 1.3.7 I had
import * as rfs from 'rotating-file-stream'and
const stream = rfs('file', opts).As of 1.3.7 the types were any, so there was no issue. As of the type definition in 1.3.8 I started seeing the error described above. By changing the import to
import rfs from 'rotating-file-stream', I was able to clear the error, but I was getting a null value for rfs when running the code. Honestly, in retrospect, it was probably because you define the export as RotatingFileStream, so I probably needed to doimport RotatingFileStream`, but that also underscores a reason why default exports are considered to be a bad practice… https://basarat.gitbooks.io/typescript/docs/tips/defaultIsBad.html@rakshith-ravi I’m not sure I understand your explanation for why you need to use default export. Other JS libraries get around it. Sure, it may take some refactoring, but it’s probably better for the health and utilization of this library in the long run.
@iccicci, I will try to clone your commit and try it out tomorrow, but I’m not sure if it relates to this issue (I could be wrong). Could you please post me a snippet of how you expect the module to be imported in TypeScript ?