Ember-intl: v4.3.1 may break ember-auto-import usage

[nightire]

• [x] I am on the latest ember-intl version
• [x] I have searched the issues of this repo and believe that this is not a duplicate

Environment

• Ember Version: 3.17.3
• Ember CLI Version: 3.17.0
• Ember Intl Version: 4.3.1
• Browser(s): any modern browsers
• Node Version: 12.16.2

NOTE: This issue is may not an actual bug, but if you encounter the same thing, this may be helpful for you.

Preconditions:

• using ember-auto-import
• import any module that relies on node API (not sure if this assumption is too widen)
• upgrade older ember-intl to v4.3.1 (or v5.0.0-beta.1)

you might see a broken build with errors related to ember-auto-import, for example:

but it's actually has nothing to do with ember-intl, even it happened just after you upgrade it.

The reason behind is due to this PR: https://github.com/ember-intl/ember-intl/pull/1230

The simple solution is to put this config into your own ember-cli-build.js:

const app = new EmberApp(defaults, {
  autoImport: {
    webpack: {
      node: {
        global: false, // or true, doesn't matter on this issue
      },
    },
  }
});

I'm not sure if this is a bug of ember-auto-import, or people should always set this config by themselves. A lot of users are using ember-intl (including me), it did this for us unintentionally in a long period of time.

[bobisjan]

A lot of users are using ember-intl (including me), it did this for us unintentionally in a long period of time.

Yes, that was unfortunate (and buggy for other use cases) behaviour of the configuration provided by this add-on, now it should be clear that some other deps need attention by application itself (jszip is not used by ember-intl at all).

ember-auto-import explicitly does not want to have this _magic_ by default https://github.com/ef4/ember-auto-import/issues/215.

Hope this helps, and thanks for making point for others 👍.

[EvgenyOrekhov]

4.3.1 broke our build:

  - broccoliBuilderErrorStack: Error: webpack returned errors to ember-auto-import

From my standpoint, it's a problem with ember-intl. If I'm mistaken, could you please explain why this happens with 4.3.1 and how to fix it properly.

[bobisjan]

@EvgenyOrekhov, I assume that the error you see now is caused by importing some dependency (complete error stack should tell which), but this dependency most likely is not related to ember-intl.

The provided configuration before the fix in 4.3.1 was broken for FastBoot environment (by mocking the global), hence the bugfix release.

If the _hidden_ config worked well for your application, you can add it directly to the ember-cli-build.js as @nightire already pointed out.
```js
const app = new EmberApp(defaults, {
autoImport: {
webpack: {
node: {
global: true,
},
},
},
});

[jasonmit]

I'll keep this issue open for visibility for the time being.

To summarize, we were masking a bug in your app. Your app was indirectly relying on ember-intl to set an ember-auto-import config option, webpack.node.global, that you have should have been setting yourself.

ember-intl no longer needs webpack.node.global on but your app still does because some other either your app or another addon is trying to import a node module that references Node's global object.

[EvgenyOrekhov]

@bobisjan The only packages I can see in the stack trace are broccoli-plugin, ember-auto-import, and ember-cli. So I have no idea which package causes the error. The global: true solution works, but I also tried global: false, and it also works. How can this be possible?

[st-h]

@EvgenyOrekhov same here. No hint in the logs which addon actually has been causing the error. Had to upgrade one dependency, build, run, repeat to find out which addon is causing the error.

@nightire thanks for opening this issue and providing a workaround. Though, I am not sure I exactly understand what is going on.

@jasonmit Can you provide details what could cause an app to indirectly rely on ember-into to set an ember-auto-import config option, which I should have been setting myself? Is this something like auto-importing an addon that has a dependency on ember-intl. Also thanks for keeping this issue open, has been quite helpful.

Oh, and it looks like our app needs global set to true. Setting it to false, leads to this error:

Uncaught (in promise) ReferenceError: global is not defined
    at eval (index.js:45)
    at Object../node_modules/buffer/index.js (vendor-suffix.js:1)
    at __webpack_require__ (vendor-suffix.js:1)
    at eval (index.js:2)
    at Object../node_modules/content-disposition/node_modules/safe-buffer/index.js (vendor-suffix.js:1)
    at __webpack_require__ (vendor-suffix.js:1)
    at eval (index.js:21)
    at Object../node_modules/content-disposition/index.js (vendor-suffix.js:1)
    at __webpack_require__ (vendor-suffix.js:1)
    at Module.eval [as callback] (app.js:19)

[jasonmit]

Is this something like auto-importing an addon that has a dependency on ember-intl.

ember-intl is not part of the problem here, your app (or an addon) is bundling a dependency in your app via ember-auto-import/webpack where one of the modules being imported references global and causes that exception to be thrown. Prior, ember-intl would tell ember-auto-import to turn global on because ember-intl needed that setting to be set. Ember-intl no longer sets this setting because it no longer needs it but your application does.

No hint in the logs which addon actually has been causing the error. Had to upgrade one dependency, build, run, repeat to find out which addon is causing the error.

Based on your stracktrace, something in your app is importing content-disposition which requires safe-buffer which requires buffer which references global. If you want to know why your app is importing this via use yarn why buffer (orsafe-buffer to help narrow things down).

[nightire]

@st-h the global option here is to refer the top-level object in Node.js environment (in browser this object is called window)

We use webpack to import 3rd-party libs, some of them use global in its source, to make them work, you have to tell webpack: please expose the global variable to those node.js compatible libs.

It's often been required in two scenarios:

1. Your application is running in SSR (FastBoot for example) and some libs you imported can work in both SSR and client, but they need global in SSR
2. You import some isomorphic libs, and they are written in node.js format but transformed by tools such as browserify so that they can work in browsers as well

I use global: false in the code snippet because my situation only matches the 2nd point, I have to tell webpack to work with node.js lib but don't have to expose the global variable.

[st-h]

Thanks a lot for the explanation. Still got to look into what is causing this in my app, but I think I understand what is happening now.