v4.3.1 may break ember-auto-import usage

• I am on the latest ember-intl version
• 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.

[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.

[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.