allow well-defined import adjustments in native v2 packages

packages/core/src/babel-plugin-adjust-imports.ts

@@ -1,4 +1,4 @@
-import { packageName as getPackageName } from '@embroider/shared-internals';
+import { emberVirtualPackages, emberVirtualPeerDeps, packageName as getPackageName } from '@embroider/shared-internals';
 import { join, dirname, resolve } from 'path';
 import { NodePath } from '@babel/traverse';
 import type * as t from '@babel/types';
@@ -279,6 +279,27 @@ function handleExternal(specifier: string, sourceFile: AdjustFile, opts: Options
     return makeExternal(specifier, sourceFile, opts);
   }
 
+  if (pkg.isV2Ember()) {
+    // native v2 packages don't automatically externalize *everything* the way
+    // auto-upgraded packages do, but they still externalize known and approved
+    // ember virtual packages (like @ember/component)
+    if (emberVirtualPackages.has(packageName)) {
+      return makeExternal(specifier, sourceFile, opts);
+    }
+
+    // native v2 packages don't automatically get to use every other addon as a
+    // peerDep, but they do get the known and approved ember virtual peer deps,
+    // like @glimmer/component
+    if (emberVirtualPeerDeps.has(packageName)) {
+      if (!opts.activeAddons[packageName]) {
+        throw new Error(
+          `${pkg.name} is trying to import from ${packageName}, which is supposed to be present in all ember apps but seems to be missing`
+        );
+      }
+      return explicitRelative(dirname(sourceFile.name), specifier.replace(packageName, opts.activeAddons[packageName]));
+    }
+  }
+
   // non-resolvable imports in dynamic positions become runtime errors, not
   // build-time errors, so we emit the runtime error module here before the
   // stage3 packager has a chance to see the missing module. (Maybe some stage3

packages/shared-internals/package.json

@@ -27,6 +27,7 @@
     "test": "jest"
   },
   "dependencies": {
+    "ember-rfc176-data": "^0.3.17",
     "resolve-package-path": "^1.2.2",
     "pkg-up": "^3.1.0",
     "typescript-memoize": "^1.0.0-alpha.3",

packages/shared-internals/src/ember-standard-modules.ts

@@ -0,0 +1,27 @@
+// I'm doing this as a json import because even though that's not standard JS,
+// it's relaively easy to consume into builds for the web. As opposed to doing
+// something like fs.readFile, which is harder.
+//
+// @ts-ignore
+import mappings from 'ember-rfc176-data/mappings.json';
+
+// these are packages that available to import in standard ember code that don't
+// exist as real packages. If a build system encounters them in stage 3, it
+// should convert them to runtime AMD require.
+//
+// Some of them (like @embroider/macros) won't ever be seen in stage 3, because
+// earlier plugins should take care of them.
+//
+// In embroider builds using ember-source >= 3.28, you won't see *any* of these
+// in stage3 because ember-source uses the standard rename-modules feature to
+// map them into real modules within ember-source.
+export const emberVirtualPackages = new Set<string>(mappings.map((m: any) => m.module));
+
+// these are *real* packages that every ember addon is allow to resolve *as if
+// they were peerDepenedencies, because the host application promises to have
+// these packages. In principle, we could force every addon to declare these as
+// real peerDeps all the way down the dependency graph, but in practice that
+// makes the migration from v1 to v2 addons more painful than necessary, because
+// a v1 addon in between the app and a v2 addon might not declare the peerDep,
+// breaking the deeper v2 addon.
+export const emberVirtualPeerDeps = new Set<string>(['@glimmer/component']);

packages/shared-internals/src/index.ts

@@ -6,3 +6,4 @@ export { default as PackageCache } from './package-cache';
 export { default as babelFilter } from './babel-filter';
 export { default as packageName } from './package-name';
 export * from './ember-cli-models';
+export * from './ember-standard-modules';