Jimp: TypeScript import won't work

[cancerberoSgx]

None of the three methods detailed in the readme worked for me when importing gimp on my TypeScript project when upgrading to [email protected]

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"]
}

[hipstersmoothie]

@crutchcorn

[hipstersmoothie]

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.

[hipstersmoothie]

If we do keep theme we definitely need some type testing @crutchcorn

[crutchcorn]

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)

[crutchcorn]

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

[hipstersmoothie]

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.

[crutchcorn]

For sure. Huge apologies for introducing a PR without doing more thorough testing (it turns out my IDE was doing some weird things to fix the mistaken type errors and I just assumed it worked) - I'm trying to prioritize getting a fix out today for it since the version was deployed

I think the plugin system is great - it's never easy to introduce one and it seems to work really well

[crutchcorn]

Issue has been resolved in PR #786 and typing tests were added to confirm functionality. Again, huge apologies

[aethys256]

I spent 1 hour trying to figure why the hell I was not able to type at all my generic mixins until I found this issue.
Reverted to 0.7.0 until a fix is out, 3rd party typing is not easy indeed, maybe considering a TS rewrite in the future for proper support.
Thanks anyway for the work 👍

[cancerberoSgx]

@crutchcorn Aja, I'm not experienced with jimp plugins, but in other projects what they do is pass the responsibility declaring plugin types to plugin authors. If you delegate this to community definetely typed then they will have the same problem. This is what project jest does for example (my idea BTW ) : https://jestjs.io/docs/en/expect#expectextendmatchers

Basically If a plugin adds a new member to an existing interface or adds new types or modifications to existing types thet are responsible of declaring those modifications / new signatures by themself.

Jimp project just need to be sure to expose the types that are susceptible of being modifiable by plugin authors.

If you need a hand with this I will be glad to help, but need your confirmation so I start familiarizing with your plugin's API and so on.

I strongly advice that, if you are interesting in supporting TypeScript definitions maintaining them here will add value and quality to this project for sure!- -will you let me know if you need a hand with it ?

THanks

[crutchcorn]

@cancerberoSgx It's not quite that easy. The plugin authors in this case is us:

https://github.com/oliver-moran/jimp/tree/master/packages/plugins

The other issue is that we're enabling composing of these packages via function ala:

https://github.com/oliver-moran/jimp/tree/master/packages/custom

Using interface merging as you're suggesting (and as jest uses) only extends the initial type without doing any strictness testing to see if the configure function actually has those values or not (no better than the original 0.7 typings in that manor)

This PR should have the typings fixed https://github.com/oliver-moran/jimp/pull/786 and introduces type testing. If you're wanting to contribute to these typings, a code review of them would be phenominal (I'd love if we're able to maintain the type scrictness for @jimp/custom as well)

[cancerberoSgx]

@cancerberoSgx

The other issue is that we're enabling composing of these packages via function ala:

Ajá, again, totally new with these APIs, and I assume you cannot solve the problem with mixings or modifying ambient modules. I will try to take a look to your code, but just in case (and this is personal opinion) in these cases I always have a small TS project between my test assets as part of my CI just to make sure the compilation doesn't fail (check the readme example works). Is not important to reflect there that plugins typings works, but just that the simple TS example in the readme don't fail.

Also another feedback - don't describe three different import methods in the readme - it's too verbose. In general you just want to describe the import statement both JavaScript and TypeScript users will use. TypeScript users knows how to configure their project to make it work - and in general when developing in the web they always use esModuleInterop - and remember they probably run the same generated JS both in node and browsers..

Last feedback: avoid default exports or assignment exports to the user - so they just can import {Jimp, create, etc} from 'jimp and JS users an analogous syntax const {Jimp, create} = require('gimp') .... course this is pretty personal taste.... Thanks , I will be alert for the PR and new npm version with this fix. And just an advice: if they got in your way, you are not forced to use namespaces or modules at all.

Thanks again! Keep it up

[crutchcorn]

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

[hipstersmoothie]

@cancerberoSgx Could you verify that v0.8.1 fixes you issue?

[patheticcockroach]

Doesn't work for me, when I do

import Jimp from 'jimp';

or

import * as Jimp from 'jimp';

with Jimp 0.8.1 from npmjs, all I get is

error TS2307: Cannot find module 'jimp'.

allowSyntheticDefaultImports is true (setting it to false seems to result in the same thing, but also a bunch more unrelated errors)

(Using TS 3.6.3 + Node 10.16.3; Last working Jimp version: 0.6.4)

[crutchcorn]

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

[amirburbea]

@patheticcockroach downgrading to 0.7.0 again works for now. Hopefully 0.8.2 will fix us.

[crutchcorn]

792 fixes the npm files whitelist and leaves two extra notes about potential other TS issues (that were not introduced in 0.8 and should not be blocking for anyone who's consumed any version of the types since ~0.5)

Thank you all for the patience on this issue. I know the 0.8 release has been rocky but I think the types are in a much much more maintainable place now (both with organization and typing tests) and I'm hoping that once this PR is merged things can move from here without too much of a hitch.

[crutchcorn]

If anyone wants to test the PR for #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 would you be able to test against this version really quick?

[amirburbea]

It worked for me

On Thu, Sep 12, 2019, 11:27 AM Corbin Crutchley [e-mail]
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
.

[patheticcockroach]

I'm now getting a bunch of those:

'Jimp' refers to a value, but is being used as a type here.

In code like:

let myImage: Jimp = new Jimp(width, height, 0);

[crutchcorn]

@patheticcockroach what version of TS are you using and how are you importing? (I think this may be a really simply fix that I can add to that PR, thank you for testing)

[amirburbea]

This is the tsconfig I am using and it fails to compile actually - I am not sure why but it seemed to work earlier.

{
  "compileOnSave": false,
  "compilerOptions": {
    "allowJs": false,
    "allowSyntheticDefaultImports": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "alwaysStrict": true,
    "declaration": true,
    "declarationMap": true,
    "disableSizeLimit": true,
    "emitBOM": false,
    "emitDeclarationOnly": false,
    "emitDecoratorMetadata": false,
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "forceConsistentCasingInFileNames": true,
    "importHelpers": true,
    "incremental": true,
    "isolatedModules": false,
    "lib": ["dom", "es2015", "es2016", "es2017.object"],
    "module": "esnext",
    "moduleResolution": "node",
    "newLine": "LF",
    "noEmitOnError": true,
    "noErrorTruncation": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitAny": true,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "noStrictGenericChecks": false,
    "noUnusedLocals": true,
    "preserveConstEnums": false,
    "preserveSymlinks": true,
    "pretty": true,
    "removeComments": false,
    "resolveJsonModule": true,
    "sourceMap": true,
    "strict": true,
    "strictBindCallApply": true,
    "strictFunctionTypes": true,
    "strictNullChecks": true,
    "strictPropertyInitialization": true,
    "stripInternal": true,
    "suppressExcessPropertyErrors": false,
    "suppressImplicitAnyIndexErrors": false,
    "target": "esnext"
  },
  "exclude": ["./node_modules/"]
}

The types load but

import Jimp from 'jimp';

export default async function() {
const font = await Jimp.loadFont(Jimp.FONT_SANS_16_WHITE); //succeeds
const output = new Jimp(400,400,'#ffffff'); // error - type is not constructable

[hipstersmoothie]

@crutchcorn you might need to add something like

interface Constructable<T> {
  new (): T;
}

[patheticcockroach]

I'm using TS 3.6.3

my tsconfig is:

{
  "compileOnSave": true,
  "compilerOptions": {
    "target": "es5",
    "noImplicitAny" : true,
    "strictPropertyInitialization": false,
    "strictNullChecks": true,
    "esModuleInterop": true,
    "lib": [
      "es5",
      "es2015.promise",
      "esnext.asynciterable"
    ],
    "skipLibCheck": false,
    "alwaysStrict": true,
    "removeComments": true,
    "typeRoots": [
      "node_modules/@types"
    ],
    "moduleResolution": "node",
    "baseUrl": ".",
    "paths": {
      "*": [
        "*"
      ]
    }
  },
  "exclude": [
    "node_modules"
  ]
}

And then in my ts files I do

import Jimp from 'jimp';

[crutchcorn]

@hipstersmoothie please revert 0.8 the typings need significantly more thoughts placed into them (I earnestly had forgotten about the constructor and it threw significant amount more loops then expected) and I've had 5 nights of maybe 3 hours of sleep each trying to work on this (and tons of stuff going on outside of this that I need to take care of)

I'll loop back in a week (I don't think the work I've done is unsalvagable - just requires more time then I have right now, I'm feeling burnout REALLY bad right now) - but I'm officially going AFK on this issue until I'm of better state of mind, more well rested, and have more of a schedule to be able to take these considerations on

[crutchcorn]

PR #792 was updated to remove the new typings for 3.1 (from being detected by TS, without actually removing the code). @hipstersmoothie if you merge, there will still be a value add to TS users for 0.8 due to the new plugins being typed, but keeps the old type interface only exposed (so even TS3.1 users will use the old typings).

@patheticcockroach please test 0.8.2-canary.792.283.0 to confirm

[amirburbea]

I downloaded the above version. I'm sorry but it still failed for 2 reasons.

1. The package.json still refers to 3.1
2. Even after I deleted that section of package.json, the 2.8 types don't seem to work either.

The problem lies here (line 414)

declare const JimpInst: Jimp;

export default JimpInst;

This is an export of a single instance of the class, so typescript can't simply new it up.

[patheticcockroach]

Same error as in my previous comment with 0.8.2-canary.792.283.0, but... is it normal that it's the exact same number as before?

[cancerberoSgx]

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,

@crutchcorn I want to understand now your argument about the complexity of these types, could you point me to a plugin or example that uses that functionality to declare its types. I just want to check out if there is a simpler way and also learn about plugins which I'm completly ignorant, normally mixings and declarations should be used for this but I can't find any example or package that declare extra types

and please don't give up on typings
thanks

[cancerberoSgx]

@cancerberoSgx Could you verify that v0.8.1 fixes you issue?

now it doesn't even find type gimp

2 import jimp from 'jimp'
~~

test/testUtil.ts:2:18 - error TS2307: Cannot find module 'jimp'.

[cancerberoSgx]

@crutchcorn

I stronly recommend to simplify this first and then tackle complexities like supporting multiple typescript versions (first time I see there's need for that) and second supporting the plugins dynamic type declaration stuff - really popular libraries like jest won't even document how to declare a plugin/helper type I had to pull request them.... I think now you can assume is user responsibilityl, simplify types, declare typescript as peer dependency if you really need to, and then with time and peace ,try yo tackle both problems separately

also assume user has latest version and if THEY have compilation error, then THEY use "skipLibCheck": true ... this problem is more common and less embarrasing that it seems, don't be afraid - let's make it work for simple use cases which are 99% and then worry about extensibility that, again, is pretty strange to find typings that support extensibility , really - and if you know a manual way then a note in the readme is more than enough - or aother alternative - let plugin authors be resposibile of providing the type and documenting in their readmes how users must hard cast a name....

[crutchcorn]

@patheticcockroach pointed out that it shouldn't be the same version I must've copied + pasted wrong. Try changing the version to 0.8.2-canary.792.290.0. If there are still errors on that version, then I'd suggest just rolling back 0.8 (I have very high confidence that version SHOULD work, as they're almost identical to 0.7)

@cancerberoSgx I have removed the ability to reference the 3.1 typings. Leaving the code-as-is in that PR will work and will not impact anything. The code is 90% working, I just need to make some changes to how classes are handled and need a break. The typings, while complex, are complex for a reason. Please check ur email

[cancerberoSgx]

wait i testing again never mind my previous comment

[crutchcorn]

Roll back 0.8

[cancerberoSgx]

@crutchcorn sorry i got confused with the numbers
this one works:

"jimp": "^0.8.2-canary.792.290.0",

although it complains about missing peers

` pm WARN @jimp/[email protected] requires a peer of @jimp/custom@>=0.3.5 but none is installed. You must install peer dependencies yourself.

using "typescript": "^3.6.3" and same config than in my first msg

[cancerberoSgx]

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

[patheticcockroach]

0.8.2-canary.792.290.0 gives me a bunch of:

error TS2749: 'Jimp' refers to a value, but is being used as a type here.

As I mentioned somewhere in one of my comments, the last working version for me was 0.6.4. Vesrion 0.7.0 gives me the same errors as 0.8.2-canary.792.290.0

[cancerberoSgx]

@patheticcockroach
suggestion: could you simplify it like this ? which ts and node version are you using ?

{ "compileOnSave": true, "compilerOptions": { "target": "es5", "noImplicitAny" : true, "strictPropertyInitialization": false, "strictNullChecks": true, "esModuleInterop": true, "lib": [ "esnext" ], "alwaysStrict": true, "moduleResolution": "node", "baseUrl": ".", } }, include: ["src", "test"] }

of if you really need to include the whole current dir at least :

include: ["./*.ts"] os something that don't force you to exclude node_modules.... ?

[amirburbea]

My use of 3.6.3 and the tsconfig above (https://github.com/oliver-moran/jimp/issues/785#issuecomment-530888084) works just fine with 0.7.0

@patheticcockroach - maybe you want to try that? It won't solve 0.8+, but it will get you closer to the latest version

[patheticcockroach]

I tried the tsconfig from https://github.com/oliver-moran/jimp/issues/785#issuecomment-530888084, I was still getting (among lots of additional errors):

'Jimp' refers to a value, but is being used as a type here.

I believe something happened in this commit https://github.com/oliver-moran/jimp/commit/7dff2878be3fadc346d15d954bbc9fd7bd749ae7
And actually, if I get inspiration from it and replace all my Jimp type annotations with typeof Jimp, like this:

  private doStuff(image1: typeof Jimp, image2: typeof Jimp): typeof Jimp {
    .... stuff
  }

the errors eventually all disappear, and version 0.7.0 "works". But this really looks dirty

[cancerberoSgx]

the errors eventually all disappear, and version 0.7.0 "works". But this really looks dirty

import jimp_ from 'jimp'
type Jimp = typeof jimp_

will save you for ugly refactor too

[hipstersmoothie]

I feel like at this point there must be something that gets it back to that behavior. If either of you want to take a stab at it I would be grateful ❤️

[jerry-sky]

When trying to build my app I get these errors all over the place using 0.8.1 or 0.8.2-canary.792.290.0:

None of that can be seen on version 0.6.8 though.

[amirburbea]

Sorry to say that 0.8.2 is also no bueno. It says can not find types for @jimp/core

[crutchcorn]

Alright y'all. I know I've been gone for a while now, but I have a new version for everyone to test. This includes typing tests for things like:

import Jimp from 'jimp'

const jimpInst: Jimp = new Jimp()

And more. Please be patient and understand if this version does not work (I am still putting a fair amount of time into this outside of my full-time job), but I'd love some feedback on:
0.8.2-canary.792.353.0

Please Read

Now, I do want to make a note:
const Jimp = require('jimp') and import * from Jimp from 'jimp'; new Jimp() DO NOT WORK

Both of these import methods were broken as-of 0.6.4 (hense why that was the last version that worked for you, ), and unless we remove all other named exports, there is nothing that can be done there.

The good news is: This should not impact the ability for your code to run.

When looking at the built version of the code, you can clearly see:

var _default = (0, _custom.default)({
  types: [_types.default],
  plugins: [_plugins.default]
});

exports.default = _default;
module.exports = exports.default;

That is to say (for those of us who don't speak ES6 Babel nonesense): The export is duplicated to have both ES6 and commonJS exports. It will work regardless of how you import it in TS (but the typings, I will remind, will not).

This is all a long TLDR that's to say: Before you test this version - please make sure to change all of your imports to use the default import Jimp from 'jimp' syntax

[crutchcorn]

FWIW, the canary release I mentioned works for our use-case in node-vibrant:

https://github.com/akfish/node-vibrant/blob/develop/packages/vibrant-image-node/src/index.ts#L8

As well as the suggested change to add in custom (that sparked this whole typing frenzy):

https://github.com/akfish/node-vibrant/issues/96#issuecomment-515717736

[patheticcockroach]

It's working quite better, I only have a couple of errors left.

The first relevant parts of code look like this:

import Jimp from 'jimp';
let finalImage: Jimp = new Jimp(width, height, 0x00000000);
return finalImage.resize(newWidth, newHeight);

and I get this error:

 error TS2322: Type 'import("[...]/node_modules/@jimp/core/types/jimp").Jimp' is not assignable to type 'import("[...]/node_modules/jimp/types/ts3.1/index").default'.
  Type 'Jimp' is missing the following properties from type 'Bmp': constants, mime, decoders, encoders

xx     return finalImage.resize(newWidth, newHeight);

The second one looks like:

import Jimp from 'jimp';
this.baseImage = await Jimp.read('filename');
this.finalImage = this.baseImage.clone()
    .resize(1, 1)
    .setPixelColor(0x00000000, 0, 0)
    .resize(width, height);

and I get this error:

error TS2339: Property 'resize' does not exist on type 'Jimp'.

XX       .resize(width, height);

No other errors, so this is clearly going in the right direction 👍

[amirburbea]

@patheticcockroach I am seeing the resize method has disappeared like you.

However I don't get this error you have
error TS2322: Type 'import("[...]/node_modules/@jimp/core/types/jimp").Jimp' is not assignable to type 'import("[...]/node_modules/jimp/types/ts3.1/index").default'

That again sounds like allowSyntheticDefaultImports/esModuleInterop are not set to true. I wonder if you might try removing the explicit assignment (Instead of let finalImage: Jimp = new Jimp(width, height, 0x00000000); try simply let finalImage = new Jimp(width, height, 0x00000000);)

For example, I use Jimp in a webpack plugin to create a splash screen for my electron app, and this canary build works for me with my code and tsconfig below.

import webpack from 'webpack';
import Jimp from 'jimp';
import path from 'path';

export class SplashPlugin {
  constructor(private readonly options: SplashPlugin.Options) {}

  apply({ hooks }: webpack.Compiler) {
    const { name, version, env } = this.options;
    const text = `${name} v${version}${env !== 'PROD' ? ` (${env})` : ''}`;
    hooks.emit.tapPromise(SplashPlugin.name, async compilation => {
      const font = await Jimp.loadFont(Jimp.FONT_SANS_16_WHITE);
      const source = await Jimp.read(path.resolve(__dirname, '../logo.png'));
      const output = new Jimp(450, 250, '#2b384b')
        .opaque()
        .composite(source, 0, 0)
        .print(
          font,
          0,
          200,
          {
            text,
            alignmentX: Jimp.HORIZONTAL_ALIGN_CENTER,
            alignmentY: Jimp.VERTICAL_ALIGN_MIDDLE
          },
          450,
          50
        )
      const buffer = await output.getBufferAsync(Jimp.MIME_PNG);
      compilation.assets['splash.png'] = {
        source: () => buffer,
        size: () => Buffer.byteLength(buffer)
      };
    });
  }
}

export namespace SplashPlugin {
  export interface Options {
    name: string;
    version: string;
    env: 'DEV' | 'PROD' | 'UAT';
  }
}

{
  "compileOnSave": false,
  "compilerOptions": {
    "allowJs": false,
    "allowSyntheticDefaultImports": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "alwaysStrict": true,
    "declaration": false,
    "disableSizeLimit": true,
    "emitBOM": false,
    "emitDeclarationOnly": false,
    "emitDecoratorMetadata": false,
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "forceConsistentCasingInFileNames": true,
    "importHelpers": true,
    "incremental": true,
    "isolatedModules": false,
    "lib": ["dom", "es2015", "es2016", "es2017.object"],
    "module": "commonjs",
    "moduleResolution": "node",
    "newLine": "LF",
    "noEmitOnError": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitAny": true,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "noStrictGenericChecks": false,
    "noUnusedLocals": true,
    "outDir": "./lib",
    "preserveConstEnums": false,
    "preserveSymlinks": true,
    "pretty": true,
    "removeComments": false,
    "rootDir": "./src",
    "sourceMap": true,
    "strict": true,
    "strictBindCallApply": true,
    "strictFunctionTypes": true,
    "strictNullChecks": true,
    "strictPropertyInitialization": true,
    "stripInternal": true,
    "suppressExcessPropertyErrors": false,
    "suppressImplicitAnyIndexErrors": false,
    "target": "esnext"
  },
  "exclude": ["./node_modules/"]
}

[amirburbea]

@patheticcockroach - a temporary workaround to the resize method could simply be module augmentation.

declare module '@jimp/core'{
  class Jimp {
    resize(x:number,y:number):this;
  }
}

import Jimp from 'jimp';

function doSomething() {
   const output = new Jimp(450, 250, '#2b384b').resize(10, 10).opaque()
...

[patheticcockroach]

allowSyntheticDefaultImports was already set to true, and removing the explicit assignment didn't change things. However, adding this:

declare module '@jimp/core'{
  class Jimp {
    public resize(x: number, y: number): this;
  }
}

as you suggested, fixed both errors

[crutchcorn]

I am able to recreate the issue described by @patheticcockroach. It seems the this keyword is not behaving as I'd expect. Let me see if I can fix it.

[patheticcockroach]

The resize method definition simply seems to have been omitted in @jimp/core/types/jimp.d.ts ;)

[crutchcorn]

The resize method shouldn't be on @jimp/core. It should be in @jimp/plugins-resize. The reason these typings are so difficult and complex is because we're trying to get TS typings for 3.1+ to follow the plugin system in a type strict manor. The issue comes from this line:

https://github.com/oliver-moran/jimp/blob/f5db61068f71f7ceef563bbd08ab0d8f78f82454/packages/core/types/jimp.d.ts#L114

Where this is returning @jimp/core Jimp instance as opposed to the intersected value with all of the plugins:

https://github.com/oliver-moran/jimp/blob/f5db61068f71f7ceef563bbd08ab0d8f78f82454/packages/jimp/types/ts3.1/index.d.ts#L27

[crutchcorn]

@cancerberoSgx I'm wondering if we're wanting to move forward with the PR in #792, close this ticket, then make a new ticket for the concern with clone that @patheticcockroach mentioned. At least then MOST jimp usages should work, and we can start tracking those issues a bit better (and with a smaller scope). What do you think? I'm still trying to figure out the right way to solve against the this issue

[crutchcorn]

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

If this commit works, the typings WILL fully work, but will not utilize the new plugin system. @jimp/custom will still have the issues with clone, but my thought is, with this new release we can fix jimp, then merge that commit, create a new release, close this issue, then create a new issue for the new typings and custom, then fix those immediately after (so long as we have a working jimp typings)

[patheticcockroach]

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

It works! :)

[crutchcorn]

@patheticcockroach when you get a chance, it'd be great if you can test against #798 (with the same import restrictions of 0.8.3 [which was the last version you said worked - it got published]). If that works, then the 3.1 TS migration should be complete. I am so sorry this was such a frustrating lengthy process. The type tests put in place should DRASTICALLY reduce the potential for this type of thing to happen again

[crutchcorn]

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'

[wwarby]

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.

[amirburbea]

If you need to use that old = require syntax, you don't have
esModuleInterop/allowSyntheticDefaultImports both on.

On Sun, Sep 22, 2019, 7:13 AM William Warby [e-mail]
wrote:

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.

—
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=AAQGPCSPGPCIAT4ZAZVYTSDQK5HMZA5CNFSM4IUSDLGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7JD7SA#issuecomment-533872584,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAQGPCRL4LAKQ5RZZSOEGY3QK5HMZANCNFSM4IUSDLGA
.

[wwarby]

Urgh. You're right. But when I turn both those on, about 10 other imports in my project break. import * as moment from 'moment'; for example no longer compiles, and changing that to import moment from 'moment'; doesn't help. I'll stick with the old syntax for now - at least everything was working that way - cheers.

[cancerberoSgx]

@crutchcorn New version is working OK for me but I leave in your hands closing this issue. BTW I don't need to add any special configuration in tsconfig.json . THanks!

[crutchcorn]

@cancerberoSgx I am unable to close this. I'd love if you would be able to