Repository navigation
WebAssembly support not easy to find #16952
Description
Activity
Hi, thanks for the issue!
Maybe I’m misunderstanding, but
WebAssemblysupport is there in Node 8 & 9, with or without the flag.All the functions are there:
$ node > process.version 'v9.0.0' > WebAssembly.compile [Function: compile]
So I guess the real issue here is that
WebAssemblyis displayed as{}in the console?Yep @addaleax .
WebAssembly (formerly wasm) should show its available API, IMHO.
Just like i.e. console:
console Console { log: [Function: bound consoleCall], info: [Function: bound consoleCall], warn: [Function: bound consoleCall], error: [Function: bound consoleCall], dir: [Function: bound consoleCall], time: [Function: bound consoleCall], timeEnd: [Function: bound consoleCall], trace: [Function: bound consoleCall], assert: [Function: bound consoleCall], clear: [Function: bound consoleCall], count: [Function: bound consoleCall], countReset: [Function: bound countReset], Console: [Function: Console], debug: [Function: debug], dirxml: [Function: dirxml], table: [Function: table], group: [Function: group], groupCollapsed: [Function: groupCollapsed], groupEnd: [Function: groupEnd], markTimeline: [Function: markTimeline], profile: [Function: profile], profileEnd: [Function: profileEnd], timeline: [Function: timeline], timelineEnd: [Function: timelineEnd], timeStamp: [Function: timeStamp], [Symbol(counts)]: Map {} }--R
I think a good solution would be to solve this by taking
@@toStringTaginto account as a fallback when computing the constructor name inutil.inspect. That’s kind of easy to do, so I’m labeling this as a good first issue if anybody wants to grab it.Is this actually incorrect? It matches what all the browsers do... Chrome is the only one that shows the internals but they're faded like private properties are usually.
@apapirovski I think not displaying the methods is correct, yes. But I think there really should be output that distinguishes
WebAssemblyfrom a simple{}.Reacted by Roberto Malatesta and Marvin Hagemeister@addaleax but it matches browser consoles and that's generally been at least partially our goal.
I feel it as a lack of interactive documentation.
@apapirovski I think the goal of
util.inspectis to be as helpful as possible … if we can be more helpful than browsers I’ll take it. (And yes, helpful is very subjective. 😄)Reacted by Anatoli Papirovski and metabenchWebAssembly examples online still use wasm and instantiateModule.
Having a JS object exposing its public methods is a good practice imho.--R
@RobertoMalatesta To be clear, what I’m suggesting is to switch to something like
WebAssembly {}as the displayed output, because we generally stick with what the object says – if its properties are not enumerable, then we won’t show them in the console either by default.The methods are all there, it’s really just a question of how to display the object in question.
Fine for me if there's an easy way to follow its API development (not only for me but for anyone interested).
util.inspect returns {} btw
So, where a user should see the info on WebAssembly module?
(it's not in oficial doc on main site)Thanks for your work, (just trying to be of help).
--Roberto
I'm still not convinced we should be doing anything differently.
The WebAssembly object is the initial value of the WebAssembly property of the global object. Like the Math and JSON objects, the WebAssembly object is a plain JS object (not a constructor or function) that acts like a namespace and has the following properties:
https://github.com/WebAssembly/design/blob/master/JS.md
It's a plain JS object with non-enumerable properties. It's not a class, constructor, whatever. Naming it as
WebAssembly {}seems misleading.Reacted by Jesse Schalken19 remaining items
I mean, that's what
util.inspect(WebAssembly, true, 0)is for. It would be a bit weird to make an exception for JSON, Math & WebAssembly.Reacted by MK and Chris Cowani think we're all in agreement at this point. 👀
Well, I think there's a merit here to saying that
showHiddenshould be on by default in REPL, then this would not be an issue. It would make our logging more similar to what the Chrome console does but less similar to Safari, Firefox & Edge.+1 to using showHidden in REPL
@apapirovski i'm not so sure about this behavior, my only thought is to apply separate depth limits to enumerable and non-enumerable properties on util.inspect
@mscdex It's not a name space, but the
@@toStringTagname. IMO I see no harm in displaying those for a better description whenconstructor.nameis too vague.@joyeecheung In these cases, the
@@toStringTagis just returning the name of the global variable (e.g.Math,JSON, etc.), so I would call that a namespace, especially since they are not constructors (or functions at all).@mscdex But this does not have to be about those built-in obejects. Considering this:
var foo = {}; Object.defineProperty(foo, Symbol.toStringTag, { value: 'Foo', enumerable: false })
IMO in this case it's reasonable to display foo as
Foo {}.constructor.nameis just one way to get the class/type name, but not every object is supposed to be constructed by a constructor or by callingnew.@joyeecheung Using the same notation as constructor names is misleading and inconsistent.
@joyeecheung @mscdex It would be nice if you could chime in at what’s being discussed in #16956 (comment) as a solution
Thanks for your time,
--Rob