Issue 1:
Bug report

What is the current behavior?

Running webpack throws an exception that acorn cannot be found:

[webpack-cli] Error: Cannot find module 'acorn'
Require stack:
- [root]\node_modules\acorn-import-assertions\lib\index.js
- [root]\node_modules\webpack\lib\javascript\JavascriptParser.js
- [root]\node_modules\webpack\lib\javascript\JavascriptModulesPlugin.js
- [root]\node_modules\webpack\lib\WebpackOptionsApply.js
- [root]\node_modules\webpack\lib\webpack.js
- [root]\node_modules\webpack\lib\index.js
- [root]\node_modules\webpack-cli\lib\webpack-cli.js
- [root]\node_modules\webpack-cli\lib\bootstrap.js
- [root]\node_modules\webpack-cli\bin\cli.js
- [root]\node_modules\webpack\bin\webpack.js
at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
at Function.Module._load (node:internal/modules/cjs/loader:778:27)
at Module.require (node:internal/modules/cjs/loader:1005:19)
at require (node:internal/modules/cjs/helpers:102:18)
at Object.<anonymous> ([root]\node_modules\acorn-import-assertions\lib\index.js:8:38)
at Module._compile (node:internal/modules/cjs/loader:1101:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
at Module.load (node:internal/modules/cjs/loader:981:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
at Module.require (node:internal/modules/cjs/loader:1005:19) {
code: 'MODULE_NOT_FOUND',
requireStack: [
'[root]\\node_modules\\acorn-import-assertions\\lib\\index.js',
'[root]\\node_modules\\webpack\\lib\\javascript\\JavascriptParser.js',
'[root]\\node_modules\\webpack\\lib\\javascript\\JavascriptModulesPlugin.js',
'[root]\\node_modules\\webpack\\lib\\WebpackOptionsApply.js',
'[root]\\node_modules\\webpack\\lib\\webpack.js',
'[root]\\node_modules\\webpack\\lib\\index.js',
'[root]\\node_modules\\webpack-cli\\lib\\webpack-cli.js',
'[root]\\node_modules\\webpack-cli\\lib\\bootstrap.js',
'[root]\\node_modules\\webpack-cli\\bin\\cli.js',
'[root]\\node_modules\\webpack\\bin\\webpack.js'
]
}

NOTE: node_modules/webpack/node_modules/acorn exists, but this is invisible to node_modules/acorn-import-assertions since it's at the wrong level (I think).

If the current behavior is a bug, please provide the steps to reproduce.

I need some time to create a repro, let me know if it's needed.

It seems to happen though when another dependency in the same project has a version-incompatible dependency on acorn (e.g. 7 instead of 8) leading to acorn being duplicated and pushed deeper inside the tree.

What is the expected behavior?

Other relevant information:

webpack version: 5.65.0

Node.js version: 16.13.1

Operating System: Windows 11

Additional tools: npm 8.3.0

Issue 2:
Update: On further investigation, it seems that there's a very significant mismatch between webpack Wasm semantics and the early draft proposed standard, in terms of when Wasm instantiation happens. I'm happy to have the help of the webpack team here, with your experience this space and success building a working system. Let's keep discussing this to figure out what semantics should be standardized.

Feature request

The WebAssembly CG is working on standardizing the integration of WebAssembly modules and ES Modules. The proposal's semantics are very similar to what webpack's experimental WebAssembly support. However, there may be some minor differences. This issue is intended to be an umbrella bug to track the general effort to add tests against the new proposal and semantic changes to match it.

What is the expected behavior?

That webpack's WebAssembly module support would match the new specification.

What is motivation or use case for adding/changing the behavior?

All documentation about wasm and ESM (the spec itself, MDN, other developer resources) could match up with webpack's implementation

Bring compatibility among bundlers, to make things easier for programmers

Make native modules and webpack behave the same, in case the same code may be used both with webpack and as a native module

How should this be implemented in your opinion?

Let's start with tests. Long-term, it'd be best if tests are part of web-platform-tests and imported into webpack; that's a bit of an unsolved problem for now, though, so the initial plan is to develop tests directly against webpack in a PR.

Test plan:

Convert the remaining .wasm tests to .wat for easier development

Exports of globals from Wasm are imported as WebAssembly.Global

objects, not Numbers (this looks likely to be an existing spec violation)

Imports of Numbers become only immutable, not mutable, Global objects,

and undergo rounding based on the declared type

A WebAssembly.Table, Memory or Global instance, or exported Wasm

function, exported JS -> Wasm -> JS, comes out with the same identity

A cycle Wasm <-> JS, with Wasm on top, leads to a TDZ error for

Memory, Global or Table, but hoisted functions work, and Wasm things are

all initialized by the time the JS top-level statement runs

A cycle JS <-> Wasm, with JS on top, lets Wasm's start function access

Memory, Global, Table and functions, but using Wasm exports too early

leads to TDZ

Variables imported JS -> Wasm are snapshotted (whether you overwrite a

bare Number or function, or an entire Memory, Global or Table object

which isn't replaced when the variable containing it is overwritten)

Memory, Table and mutable Global can be mutated by JS code that's

called out from Wasm code, and the mutations are observed from Wasm

LinkError results if there is a type mismatch when importing into

WebAssembly (whether it's from JS or Wasm)

Circular Wasm modules result in an error before any start function

executes

All Wasm modules in the module graph are validated before any start

function runs or JS modules are evaluated; failing validation throws a

CompileError

The same Wasm module can be imported multiple times (both from JS and

Wasm) and only one copy of it is made (1 start function evaluation, 1

memory/table/global identity, etc)

The name (number) of exported functions, and the enumeration order of

exports overall, matches the JS API specification

Wasm modules can be imported from an ordinary import inside an inline

a JS module and a dynamic import from either a script or a JS module

Some parts of the semantics will probably be different in webpack and with native ESM; these tests might only be landed in wpt and not in webpack:

The return value of import() for a Wasm module is a

module namespace exotic object, similar to that of native modules

(WebPack will need to take shortcuts here)

The same resource can be used both as a Wasm module as

well as through instantiateStreaming, and there's no observable

caching/sharing between these

The choice between interpreting as JS and Wasm is

based on the mimetype and nothing else; many URL types work (blob, data,

served from SW), CSP is checked appropriately, the modern CORS settings

are used for the fetch, etc.

Are you willing to work on this yourself?

I plan to start implementing the test plan described above. (I wouldn't mind help here, cc @Ms2ger @xtuc) I am not sure when I would have time to implement the changes in webpack; definitely not before the end of this year.