jimp: TypeScript import won't work
None of the three methods detailed in the readme worked for me when importing gimp on my TypeScript project when upgrading to jimp@0.8.0
I couldn’t even access the right type so at least I can force a cast to require(‘gimp’). The error I’m seeing in the suggested methods is that the type resolved to never.
I’m using typeScript 3.6.2 , and node 12.8.1. I also tried with all combinations of esModuleInterop and allowSyntheticDefaultImports as the readme mention but without luck. I feel competent with TypeScript and I really think you have something wrong with your type declarations. It would be awesome if you could just export the constructor type - in my case I need to cast the Jimp class, as in new Jimp(). Also, just an opinion, these type declarations are unnecessary complex I think. Any tip is most welcome, thanks. This is my tsconfig.json
{
"compilerOptions": {
"target": "es5",
"module": "commonjs",
"lib": ["esnext", "dom"],
"strict": true,
"esModuleInterop": true,
// "allowSyntheticDefaultImports": true,
"sourceMap": true,
"outDir": "./dist",
"rootDir": ".",
"declaration": true
},
"include": ["src", "test"]
}
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 7
- Comments: 64 (23 by maintainers)
This issue should be solved as-of 0.8.4. I’d love to see it closed.
Please keep in mind that, per the updated README,
import * from Jimpandconst Jimp = require('jimp')will not work as-expected. Please update to usingimport Jimp from 'jimp'This doesn’t seem to be fixed as far as I can see.
const Jimp = require('jimp');works fine, but if I useimport Jimp from 'jimp';I seeCannot read property 'read' of undefinedthe first time I try to use Jimp:
const image = (await Jimp.read(buffer));I’m using version 0.8.4.
Working on it more today and I think I have it fixed
That said, I am writing dts-lint tests (the same in DefinitelyTyped) to try to ensure to the best of my abilities it will work
Seriously considering moving the definition to definitely typed. There have been countless issues around managing the types in this project.
I love typescript but I’m starting to believe that if a library isn’t shipped in TS it shouldn’t try to ship .d.ts files too.
It works! 😃
Hey man take it easy… , it’s just types, is not even real code ! thanks for the effort… and for the email - let’s try to have typings here… personally I didn’t had good experiences pushing things in DT repo
It worked for me
On Thu, Sep 12, 2019, 11:27 AM Corbin Crutchley notifications@github.com wrote:
This gave me a heart attack until I looked at it really quick this morning - good news is this is a trivial fix. When doing testing for TS, in order to avoid issues with
yarn linkI copied + pasted thepackagesfolder. As a result, I forgot to update the build scripts and both@jimp/coreandjimpdo not copy theirtypesfolder to the final build, thus causing the error above. I was able to repro the issue and resolve it only by copying thetypesfolder of each into their respectivenode_modulesfolder.I’ll have a PR open that should fix this, should be a really small lift
Said PR introduces fairly complete typing tests (that tests against 2.8 all the way to 3.6 using
dtslint, the official tool used by Microsoft itself to test types) to hopefully reduce the type’s breakage in the future.We’re also shipping a version of the typings for 2.8 seperate from the ones for 3.1+ (as those are built on top of the plugin system and require some functionality that older versions of TS dont have).
As for the documentation of various import methods - I think that’s a seperate set of concerns. I don’t know if that’s related to the work being done on typings here
Also, regarding default exports - this is a two-fold problem:
I can’t in many instances due to the acutal IO of the module having a default export. To not default export in these instances is problematic as then the types dont reflect the package typing properly
I am trying to do so in many of the places. EG,
Jimpis an exported named class from@core/jimpas well as having a default export of an instance of that classI think that should help with future PRs for types too. Thanks for your work!
It’s my fault for the plugin system 😅 If any fingers should be pointed for needless complexity it’s at me lol.
Blech, I tried to test myself but musta dropped the ball somewhere - okay. I’ll see if I can write some tests tomorrow and get a PR to fix this
I totally get if we want to move the types to their own repo. I’m willing to maintain these types for this repo, and I feel that when typings are moved out of a project they’re maintained to a lesser degree and they suffer as a result, but that’s my initial thoughts
@cancerberoSgx, regarding the type complexity - I agree that they’re just complex but they’re forced to be so if the plugin system is able to be properly and strictly typed. While it’s unfortunate that such complex typings are required, I sincerely did my very best to document things as I could and make the typings as verbose and clear as possible (I’d love feedback on how they might be made more straightforward without removing the plugin functionality - it’s within huge possibilities I missed something obvious)