Uncaught TypeError: Cannot read property 'getSync' of undefined
ytetsuro opened this issue · comments
magickApi.js:78 Uncaught TypeError: Cannot read property 'getSync' of undefined
at Object../node_modules/wasm-imagemagick/dist/src/magickApi.js (magickApi.js:78)
success after removing .default on line 78
The tsconfig.json is not even strict, letting import StackTrace from "stacktrace-js" evade from type check.
esModuleInterop is actually enabled in tsconfig-esm5.json, but it's missing in tsconfig.json. So I suppose dist/bundles/wasm-imagemagick.esm-es5.js, specified as module in package.json, which is built with tsconfig-esm5.json, would run normally.
However, if our build system happens to read the main entry, which points to dist/src/index.js built with tsconfig.json, the error will arise.
it still shows the err...
my version is 1.2.7
delete .default at line 78 doesn't work, it still shows the err ReferenceError: Worker is not defined
is there anybody who still fix it?? the lib is terrible...
@wind4gis I originally wrote this code directly in es6. cancerberoSgx came along and added in type script, tests and npm support.
From what I understand es5 is not working for commonjs. @Axure wrote a PR to address this issue, however it breaks the tests. I reran the tests today to validate they are in fact still failing.
@wind4gis you are more then welcome to adopt @Axure's PR and resubmit a forked version that doesn't break the tests
I will assure you the library does work, it has been used to save over 2500 hours of artists' time at https://knicknic.github.io/croppy
You can view the entirety of the source code for in that page (not minified) or at https://github.com/KnicKnic/croppy
I also get this error, any steps to fix it?
I have done something like this now and it works like a charm, a bit hacky though:
<script type="module">
import * as Magick from "https://knicknic.github.io/wasm-imagemagick/magickApi.js";
window.magick = Magick;
</script>
I have also experienced this issue, and hacked around it by commenting out lines 78 and 79.
The offending lines (corrected):
let stacktrace = stacktrace_js_1.getSync();
currentJavascriptURL = stacktrace[0].fileName;
The commenting out vs removing .default is due to a separate issue which I will deal with later.
I believe the problem may be because of a library issue. Perhaps the older versions of the library require .default, while newer ones have a breaking API change.
Another option could be how the code is injected into the application. I am using a combination of Laravel Mix (WebPack) and TypeScript to compile everything (and when working) produce a minified production build. It could be that one or both of these get rid of the .default.
I'm importing this package into a react app, and encountering this problem. Deleting the .default works, but is there a workaround that doesn't involve modifying the contents of my node_modules, as this will be undone when it is built by my CI pipeline?
I'm not familiar with the React build process, but you may be able to alias "stacktrace-js" to your own file, then use that to point wherever you want. This also has the advantage of not having the code try to look for the other .js and .wasm files inside of webpack.
Another option, is I noticed that the source .ts files in this repo don't have that problem, so you could try pulling this down and compiling it from scratch. Either the npm package needs to be re-compiled or if there's something strange going on with the build process resulting in this error.
We got @Lagily's solution working, and then we found that we could use "wasm-imagemagick": "1.1.0" using npm, which avoided the issue in the first place, fyi.
@jaredscheib @KnicKnic Is using 1.1.0 safe? Are there any security concerns with using an older version of the module?
Edit: Ah I can't use it anyway without re-writing a lot of typescript.
@JohnForster I can't vouch for it in the way it sounds like you're asking, but I don't see anything in the changelog that indicates that there have been any security vulnerabilities that have been patched in the two releases since. My team and I thought to try 1.1.0 because it's the version being used i n the CodeSandbox demo example given in the README for the project: https://codesandbox.io/s/wasm-imagemagick-basic-demo-y00u2. You could also try 1.2.0 and see if that works? Or, as @EmperorArthur mentioned above, you could just compile this repo from source, and it may work then: #53 (comment). Good luck!
My solution was to use patch-package to edit that line after installing dependencies. Worked really well. THanks anyway @jaredscheib
@jaredscheib @KnicKnic Is using 1.1.0 safe? Are there any security concerns with using an older version of the module?
Edit: Ah I can't use it anyway without re-writing a lot of typescript.
1.1.0 is file, now with respect to this bug, I would love if someone could fix it and not regress existing code. (which why I have not merged Axure's patch)
@JohnForster I can't vouch for it in the way it sounds like you're asking, but I don't see anything in the changelog that indicates that there have been any security vulnerabilities that have been patched in the two releases since. My team and I thought to try 1.1.0 because it's the version being used i n the CodeSandbox demo example given in the README for the project: https://codesandbox.io/s/wasm-imagemagick-basic-demo-y00u2. You could also try 1.2.0 and see if that works? Or, as @EmperorArthur mentioned above, you could just compile this repo from source, and it may work then: #53 (comment). Good luck!
There are a few security alerts that are raised for this project by a github bot.... I should start merging some of them in, however since I use this project on a completely static website I am not too concerned about users hacking themselves.