Test v2 addon as a type=module package

[NullVoxPopuli]

Ran in to an issue with type=module over here ember-primitives#33 - ci-logs
and wanted to see if it was reproducible in a stripped down environment (it is!)

[ef4]

I found an approach that fixes this particular case:

diff --git a/packages/webpack/src/webpack-resolver-plugin.ts b/packages/webpack/src/webpack-resolver-plugin.ts
index b832434d..c0286b94 100644
--- a/packages/webpack/src/webpack-resolver-plugin.ts
+++ b/packages/webpack/src/webpack-resolver-plugin.ts
@@ -165,6 +165,7 @@ class WebpackModuleRequest implements ModuleRequest {
     if (this.fromFile === newFromFile) {
       return this;
     } else {
+      delete (this.state as any).resolveOptions;
       this.state.contextInfo.issuer = newFromFile;
       this.state.context = dirname(newFromFile);
       return new WebpackModuleRequest(this.babelLoaderPrefix, this.appRoot, this.state) as this;

The reason our initial attempt to mutate this.state.resolveOptions.byDependency.esm.fullySpecified didn't work is that webpack is doing a === on the resolveOptions to reuse a cached resolver. The resolveOptions seem to be optional, so deleting them is one solution. It also works if you clone the options first to give them a different object identity.

Next step here would be to figure out what we need to do with resolveOptions to be correct in all the cases. Is leaving it off OK? Are we obligated to recreate it in cases where we're rehoming a request into a package that actually needs fullySpecified: true?

A related question is: can we stop mutating this.state when we adjust webpack requests and instead produce complete valid new states? This would mean changing all the places where we pass this.state to new WebpackModuleRequest to instead derive a new state object. This would also solve the problem because we wouldn't accidentally carry across something like this option that we don't want to keep in the new request. The challenge is making sure we include exactly what's needed.

[NullVoxPopuli]

looks like this is a problem with importSync

I can't reproduce the behavior in the tests correctly, but
this simple file causes an error:

import { importSync } from '@embroider/macros';

export const two = 2;

importSync('./violations.css');

without importSync, type=module appears to work ok.
the error:

odule not found: Error: Can't resolve '../../node_modules/.pnpm/@embroider+macros@1.13.3/node_modules/@embroider/macros/src/addon/es-compat2' in '/home/nvp/Development$TMPDIR/type-module-test/type-module-test/dist/index.js'
Did you mean 'es-compat2.js'?
BREAKING CHANGE: The request '../../node_modules/.pnpm/@embroider+macros@1.13.3/node_modules/@embroider/macros/src/addon/es-compat2' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

[NullVoxPopuli]

Looks like there are a few things happening here -- gonna have separate issue for them all.

• The original issue, which this PR is concerned with: type=module packages are not translated correctly if they are v2 addons #1674
• A new issue, which isn't related to this PR or the above importSync breaks the builds of apps consuming type=module packages #1672
• type=module is somehow incompatible with babel #1675

[NullVoxPopuli]

Info from @mansona,
we might need 9e7d875 or browserify/resolve#320 to support it

[mansona]

@NullVoxPopuli is it worth trying again since #1686 was merged and we support the exports with require.resolve now?

[NullVoxPopuli]

I found that things work ok in the test environment without interacting with the @embroider/macros, but in the latest commit, #e7a924e, I added some macros usage to re-break the test.

Basic type=module support (ie #1674) now works, but it seems we have some compat stuff to do