Closed mubaidr closed 4 years ago
Are you using TypeScript @mubaidr ?
FWIW, I'm using TS, trying to call the configure
code, and hitting the same problem. However, if I try using the values that TS is clearly MEANING to handle, it is not hitting this problem.
Adding the following into my TS config has fixed the problem:
"esModuleInterop": true,
"allowSyntheticDefaultImports": true,
I admit total fault for removing this from the README. I'll make a PR to add this back
I realized that there is two different problems going on here. There's an issue I'm having using default that requires docs changes to add the:
"esModuleInterop": true,
"allowSyntheticDefaultImports": true,
Back in, and another that is likely related to the PR you linked. I'm looking into it currently
With the babel stuff I really don't know what to do. It's either:
🤷♂
This is one of the many engineering contraints in maintaining any library. I'd suggest finding a stance you approve of and maintaining it (as it's your codebase as the maintainer).
I tend to lean towards adding polyfil stuff as it reduces the workload of maintainers like you and I (who I'm certain only do this as a side-project), but there's little-to-no perfect answer for this
I think there's more work that can be done with babel as well - I'm going to see about upgrading the corejs version and fixing this problem at the same thing, as it's impacting https://github.com/akfish/node-vibrant/issues/96. Let me know if you change your mind on the way things are done and don't want to do more with babel and rather just remove it
I'd love to just target node 8 + browser. node 8 has all es6 and es7 so the could should mostly be fine. for older browsers I think we would need to include babel stuff.
I really don't care either way, just as long as we go with the majority of use cases.
I think that's a good idea too - especially given that Node 8 is now LTS. I'll throw together a PR to upgrade deps and change some of the babel stuff and see if I'm able to drop it
same problem here, and unfortunately the tsconfig update didn't help
"esModuleInterop": true,
"allowSyntheticDefaultImports": true,
I have a webpack build which is deployed to AWS lambda
Same here. Nothing works when I try to import Jimp in ts file :(
same here, even when using plan js with serverless-webpack downgrading back to 0.6.4 fixes the issue
Same here, thanks to @vanerleo, downgrading to 0.6.4 is my workaround for now.
I'm working in electron w/ webpack and seeing the same error as the original poster in Jimp 0.8.5.
The standard workarounds that have worked for me w/ other projects don't seem to be doing the trick, ie:
"presets": [
["@babel/preset-env", {
"useBuiltIns": "usage",
"corejs": 3
}],
"@babel/preset-react"
],
and
["@babel/plugin-transform-runtime",
{
"regenerator": true
}
]
I've also tried telling webpack to explicitly run babel-loader on jimp via the following updated webpack rule:
{
test: /\.js$/,
//exclude: /node_modules/,
exclude: /node_modules\/(?!(jimp)\/).*/,
use: [
{ loader: "babel-loader"}
]
},
but no dice..
Similar to @vanerleo and @RomainFallet - i've had to revert to v0.6.4 to run.
Please feel free to pull in a simple electron project that shows the problem (and does a basic demo of jimp): https://github.com/andrewrt/jimp-ef6 (Running in 0.6.4 - if you upgrade back to 0.8.5 - breaks on both windows & osx)
While I'm not using typescript - was thinking the above babel stuff should cover me...
@andrewrt @RomainFallet can you test against 0.8.6-canary.815.488.0
to confirm a fix? I have tested against node-vibrant
and it seems to be working for me
@crutchcorn I tried using the version you have here and when I invoke my lambda function with Serverless (aws, serverless, lambda), I get a different error:
{ "errorType": "TypeError", "errorMessage": "Cannot assign to read only property 'exports' of object '#<Object>'", "trace": [ "TypeError: Cannot assign to read only property 'exports' of object '#<Object>'", " at Object.<anonymous> (/var/task/webpack:/node_modules/@jimp/core/es/request.js:34:10)", " at Object.call (/var/task/handler.js:9:283271)", " at r (/var/task/webpack:/webpack/bootstrap:19:22)", " at Module.call (/var/task/handler.js:25:14004)", " at r (/var/task/webpack:/webpack/bootstrap:19:22)", " at Object.call (/var/task/handler.js:9:310475)", " at __webpack_require__ (/var/task/webpack:/webpack/bootstrap:19:22)", " at /var/task/webpack:/webpack/bootstrap:83:10", " at Object.<anonymous> (/var/task/handler.js:1:968)", " at Module._compile (internal/modules/cjs/loader.js:778:30)" ] }
Thanks for the feedback, @divinealpine. Can you show me the code you used to do imports and running?
Are you using TypeScript? (if so, what's your tsconfig.json look like and what version are you using?)
Are you using babel?
@crutchcorn Yep, using typescript.
tsconfig.json:
{ "compilerOptions": { "esModuleInterop": true, "allowSyntheticDefaultImports": true, "sourceMap": true, "target": "es6", "lib": [ "esnext", "dom" ], "moduleResolution": "node" }, "exclude": [ "node_modules" ] }
code:
`import Jimp from "jimp/es"
export const doSomething: Handler = (event: APIGatewayEvent, context: Context) => { Jimp.read('https://avatars0.githubusercontent.com/u/1192452?s=88&v=4') .then(image => { console.log('doing something'); }) .catch(err => { console.log('handle exception: ', err); }); ... } `
More details if helpful: I'm trying to import jimp in a AWS Lambda function. Lambda function runtime is set to nodejs10.x.
That debug info helps a lot. I think I have enough to debug and try to fix in the next few days, but in the meantime I'm wondering if importing frtom jimp
instead of jimp/es
fixes the problem for you (Again, temporarily just to ensure this initial issue is resolved)
I updated the import to
import Jimp from "jimp"
redeployed and then invoked the lambda function and am receiving the same error message I had above.
Workaround--just explicitly include regenerator-runtime
.
npm install --save regenerator-runtime
const regeneratorRuntime = require("regenerator-runtime");
const Jimp = require('jimp/dist')
Now it loads properly.
@divinealpine are you able to test again but against 0.8.6-canary.815.502.0
?
@crutchcorn -
I just tested using npm i --save jimp@0.8.6-canary.815.502.0
on my test project here, and it seems to be working.
Only note I see is when i run the npm install above - I get warnings saying:
npm WARN @jimp/types@0.8.6-canary.815.502.0 requires a peer of @jimp/custom@>=0.3.5 but none is installed. You must install peer dependencies yourself.
npm WARN @jimp/plugins@0.8.6-canary.815.502.0 requires a peer of @jimp/custom@>=0.3.5 but none is installed. You must install peer dependencies yourself.
... etc etc
But it appears I can ignore these and run jimp and I don't see any errors wrt the regenerator.
So looking good from my side! Thanks!!
Fantastic! Thanks for checking @andrewrt! Those warnings should go away once this hits stable IIRC
0.9.2 has been released and should not only fix this issue but TypeScript usage in general
:rocket: Issue was released in v0.9.3 :rocket:
:rocket: Issue was released in v0.9.3 :rocket:
For anyone finding this in future and still having the issue:
I am also still experiencing this in an electon project with Jimp 0.9.3 (but only when I package the app with electron-builder).
Things I tried from above which didn't work:
# tsconfig.json
"esModuleInterop": true,
"allowSyntheticDefaultImports": true,
# package.json
"@babel/runtime": "^7.7.2",
# index.ts
require("@babel/runtime/regenerator");
import * as Jimp from 'jimp/es';
The only thing I have found which did work:
# package.json
# swap "jimp" to:
"jimp-compact": "^0.9.3"
# index.ts
import * as Jimp from 'jimp-compact';
I know that it is a semi-unofficial fork, but however jimp-compact
dependency works vs jimp
seems to fix the error...
Expected Behavior
Jimp browser version should load
Current Behavior
Jimp fails to load in browser
Failure Information (for bugs)
index.js?c2d7:3 Uncaught ReferenceError: regeneratorRuntime is not defined
Steps to Reproduce
import Jimp from "jimp/es"
Screenshots NA
Context
Browser, trying to use jimp in @vue-cli project
Failure Logs