I get a Uncaught (in promise) TypeError: second argument must be an object error when I run the following code:
async function loadWasm(url) {
const fetchPromise = fetch(url)
const { module, instance } = await WebAssembly.instantiateStreaming(fetchPromise)
// [...]
}
loadWasm('http://localhost:3000/path/to/file.wasm')
Looking at the documentation, it says that the second argument of WebAssembly.instantiateStreaming (importObject) is optional, so I don't understand why the browser makes it mandatory nonetheless?
I've tested this in Firefox 78.7.0esr (64-bit) and Chrome 88.0.4324.96 (Official Build) (64-bit). In case it's of any importance, the code is transpiled with webpack 5 in a ruby on rails 6.1 application.
Update:
I opened an issue on mdn's github repository thinking the documentation might need an update. So far it seems the documentation is good so it might be an implementation issue. To be confirmed.
Update:
It's neither an implementation issue nor a documentation mistake. I posted my conclusion about this issue in the answer below.
https://github.com/WebAssembly/spec/issues/1284#issuecomment-772286062
It is required only if the module you're instantiating actually imports something.
It's marked as optional in the documentation because it's not always needed, not because we have the choice to provide it or not. It's the wasm package that dictates whether it is optional or required.
Related
The MDN website gives examples of matching patterns with unicode support, e.g.
const sentence = 'A ticket to 大阪 costs ¥2000 👌.';
const regexpCurrencyOrPunctuation = /\p{Sc}|\p{P}/gu;
console.log(sentence.match(regexpCurrencyOrPunctuation));
It works fine on stackoverflow as a snippet.
However, in a javascript codesandbox, the code throws an error:
/src/index.js: Unknown property: Sc
In a Next.js codesandbox it also throws the same error.
On the other hand, on regex101 website the pattern is correctly matched to the sentence, with ECMAScript flavor and with "gu" flag.
Additionally, in my real world Next.js Typescript project, a pattern /\P{L}/gu worked fine until yesterday when I upgraded all dependencies to latest versions. Now it throws similar error with strict mode set to true in tsconfig.json. With strict mode set to false it still works fine.
Why is this error occurring and how to use the /\p{Sc}|\p{P}/gu or /\P{L}/gu regex pattern in code?
Based on the documentation, Sc is a non-binary property. Which means you can't just use \p{Sc}; you have to use \p{Sc=some_script_name}, where the script name is taken from here.
Unfortunately, it's a bug in next.js: https://github.com/vercel/next.js/issues/19303
I'm using consoletvs/charts to display charts in my Laravel application.
This works fine in all modern browsers, but I get an syntax error (and no charts displayed) in Internet Explorer 11 and below.
Tracing it down it seems this line (from consoletvs/charts, e.g. in init.blade.php line 8) is causing the (initial) error:
data => data.json()
So the culprit is the arrow operator, not supported in IE11. Using a polyfill seems to impossible (see Is there a polyfill for es6 arrow function?).
Now my questions:
Did I miss a feature in consoletvs/charts?
Is there a "Laravel" way to solve this (e.g. using babel/babel)?
Anybody got consoletvs/charts running on IE11?
Looks like you already got the answer to your question from the suggestion you got on the GitHub issues page for ConsoleTVs/Charts.
I will be changing this library to use my other tool:
https://github.com/Chartisan
This have a babel compilation step on the front-end or a pre-compiled
one. Also, the only thing needed will be the fetch() function. This
can be polyfilled.
Just stay tunned. I am writting the docs of Chartisan, and this lib
will soon be ported to that.
Reference:
Syntax Error on IE11 #554
As suggested, you should wait for the docs of Chartisan
I am getting "'Promise' is undefined" error on IE 11, Chrome and Firefox are not giving this error.
I am using below package for OIDC client, I already submitted an issue to that author as well.
https://github.com/IdentityModel/oidc-client-js/issues/826
If I click the link SCRIPT5009 I get directed to
https://learn.microsoft.com/en-us/scripting/javascript/misc/undefined-identifier
I installed below two, the issue is still continuing
https://www.npmjs.com/package/babel-polyfill
https://www.npmjs.com/package/promise-polyfill
Also, I read articles on StackOverflow and on the web that promise errors come from using arrow functions and having ES6 code, but this issue is coming up within OIDC package so none of the code in the app giving this error.
Try to install es6-promise polyfill, You could refer to this thread: Getting Error Promise is undefined in IE11.
Rendering DraftJS Editor on IE11 gives the following error -
Invariant Violation: PluginEditor.render(): A valid ReactComponent must be returned. You may have returned undefined, an array or some other invalid object.
This same setup works fine in Chrome/FF. We already use babel for transpiling ES6.
A related Github thread (https://github.com/facebook/draft-js/issues/296) mentioned multiple versions of React (since draft includes version 15+) while my app uses v0.14... I tried this, but upgrading isn't feasible right now)
The documentation mentions using es6-shim along with es5-shim (https://facebook.github.io/draft-js/docs/advanced-topics-issues-and-pitfalls.html#polyfills). I tried this but it didn't help. I get the same error.
Anything else I might be missing? Looking forward to your inputs.
I want to use Reflect.parse in my JavaScript in Firefox.
MDN says to import this into the global object via
Components.utils.import("resource://gre/modules/reflect.jsm")
However, this results in the following error message:
Error: Permission denied for <file://> to get property XPCComponents.utils
I have tried this in Firefox 11 and Aurora.
How can I get access to Reflect.parse?
EDIT:
The error message is due to the following fragment:
Component.utils
There is no real solution to this problem. The documentation on Reflect.parse in the wiki is misleading, to say the least.
If you want a "pure" JavaScript solution in SpiderMonkey/Firefox, don't rely on Reflect.parse.
I see a lot of projects using the parser from Narcissus and I should have done the same.
EDIT: The Esprima project is an excellent implementation of the Mozilla Parser API. After replacing Reflect.parse with esprima.parse all my 150+ test cases were still green, except for 5 or so dealing with non-standard SpiderMonkey extensions like let expressions (which I find pretty impressive).