Absolute path to package is presented in the build output assets

Describe the bug When some package is using embroider-build/embroider, it includes the absolute path in the output assets. We discovered this by using the ember-fontawesome and we reported an Issue there and they redirected us to ember-get-config and we opened an issue there too but they redirected us to you.

Reproducible test case Here I’ve created a repo where the issue can be reproduced easily fa-test. If you want you can directly examine the vendor file.
Or get the repo, and do npm install and examine vendor...js file in dist folder, you should see an absolute path to one of the packages in your local machine.

Expected behavior We want deterministic builds that are absolute-path invariant (i.e. the build output shouldn’t depend on the machine or the project’s location in the file system). Sometimes we build on our local machine, but sometimes the build is done in some agent (CI/CD Azure for example). We want build outputs to be identical no matter the machine they are built on.

Desktop (please complete the following information):

• Browser: Chrome
• Version: 104.0.5112.81 (Official Build) (64-bit)

Additional context Please check the ReadMe file for more instructions about this issue.

[ef4]

Thanks for reporting.

I think the bug here is that we’re leaving runtime information in the build even in production builds that resolve all macros at build-time. I’m pretty sure this bit of code that includes the absolute paths isn’t getting used at all anyway.

The macros work differently in dev vs prod. In dev builds we do more work at runtime, which makes it much cheaper to switch between environments (like testing vs not-testing and browser vs fastboot). In prod builds we inline all the macro results at build time, which results in smaller, faster output at the cost of needing to produce entirely separate assets for different environments (primarily browser vs fastboot).

This bug probably only affects people on classic builds. Under embroider, this entire module gets optimized away because nothing is using it.

I think this might be the fix but I haven’t had a chance to test it:

diff --git a/packages/macros/src/babel/macros-babel-plugin.ts b/packages/macros/src/babel/macros-babel-plugin.ts
index 342f4e5b..385f2380 100644
--- a/packages/macros/src/babel/macros-babel-plugin.ts
+++ b/packages/macros/src/babel/macros-babel-plugin.ts
@@ -47,7 +47,7 @@ export default function main(context: typeof Babel): unknown {
     FunctionDeclaration: {
       enter(path: NodePath<t.FunctionDeclaration>, state: State) {
         let id = path.get('id');
-        if (id.isIdentifier() && id.node.name === 'initializeRuntimeMacrosConfig') {
+        if (id.isIdentifier() && id.node.name === 'initializeRuntimeMacrosConfig' && state.opts.mode === 'run-time') {
           let pkg = state.owningPackage();
           if (pkg && pkg.name === '@embroider/macros') {
             inlineRuntimeConfig(path, state, context);

[ef4]

Fixed in #1245