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)

Most upvoted comments

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 Jimp and const Jimp = require('jimp') will not work as-expected. Please update to using import 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 use import Jimp from 'jimp'; I see

Cannot read property 'read' of undefined

the 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.

Actually, @patheticcockroach can you test this one last time against 0.8.2-canary.792.360.0

It works! 😃

and need a break.

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:

If anyone wants to test the PR for #792 https://github.com/oliver-moran/jimp/pull/792 the package version (that I confirmed fixed the issue in my testing at least) released as a canary is 0.8.2-canary.792.283.0.

@patheticcockroach https://github.com/patheticcockroach would you be able to test against this version really quick?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/oliver-moran/jimp/issues/785?email_source=notifications&email_token=AAQGPCSSQ4A24KOQFQHSA7DQJJNWPA5CNFSM4IUSDLGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6SJB3Y#issuecomment-530878703, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQGPCQNZR5YQIF5GBSZHQ3QJJNWPANCNFSM4IUSDLGA .

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 link I copied + pasted the packages folder. As a result, I forgot to update the build scripts and both @jimp/core and jimp do not copy their types folder to the final build, thus causing the error above. I was able to repro the issue and resolve it only by copying the types folder of each into their respective node_modules folder.

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:

  1. 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

  2. I am trying to do so in many of the places. EG, Jimp is an exported named class from @core/jimp as well as having a default export of an instance of that class

I 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)