Implement the allow-unknown-exports option for the run command.

[peterhuene]

This PR implements the --allow-unknown-exports option to the CLI run
command that will ignore unknown exports in a command module rather than
return an error.

Fixes #2587.

[github-actions]

Subscribe to Label Action

cc @peterhuene

Details

This issue or pull request has been labeled: "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

• peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[vshymanskyy]

Wondering, maybe this should be the default behavior?

[tschneidereit]

Wondering, maybe this should be the default behavior?

As @sunfishcode explained in the linked issue, we don't want this to be the default because it means that these functions pose a risk of becoming de-facto standardized. If modules start being used widely that export functions under names that future standards might want to use, then we'd risk behavior changing in weird and unexpected ways, so we'd likely be forced to choose different names.

This isn't a theoretical concern either: it's the reason why {String, Array}.prototype.includes} isn't called contains, to give just one example.

[sunfishcode]

Looks good to me. I recognize the practicality of having this option available 😄 .