ReferenceError when using an AtlasKit Field component

Hi there,

we are writing a connect app using AtlasKit and try to render a component (from AtlasKit). When the component renders we get the following errors

Uncaught ReferenceError: process is not defined
at VM20320 contact-person-edit-dialog.js:2233
at commitHookEffectList (VM20320 contact-person-edit-dialog.js:55005)
at commitPassiveHookEffects (VM20320 contact-person-edit-dialog.js:55029)
at HTMLUnknownElement.callCallback (VM20320 contact-person-edit-dialog.js:37871)
at Object.invokeGuardedCallbackDev (VM20320 contact-person-edit-dialog.js:37921)
at invokeGuardedCallback (VM20320 contact-person-edit-dialog.js:37978)
at commitPassiveEffects (VM20320 contact-person-edit-dialog.js:56496)
at wrapped (VM20320 contact-person-edit-dialog.js:68671)
at flushPassiveEffects (VM20320 contact-person-edit-dialog.js:56544)
at renderRoot (VM20320 contact-person-edit-dialog.js:57087)
The above error occurred in the <Field> component:
in Field (created by Form)
in form (created by Form)
in Form (created by MsUserPicker)
in MsUserPicker (created by ContactPersonMacroEditDialogUserLoggedIn)
in div (created by ContactPersonMacroEditDialogUserLoggedIn)
in ContactPersonMacroEditDialogUserLoggedIn (created by EditDialog)
in div (created by EditDialog)
in EditDialog

Looks like requires the module process, which for whatever reason does not end up in the compiled JS.
Has anyone seen this before and knows how to fix this?

Thanks, Tino

Looking at the source code of the component you are using, it is trying to access the global variables process.env.NODE_ENV and process.env.CI. Those would normally be only available in a Node.js environment, but some frontend build tools (like webpack) have or used to have support for these and substitute them with static strings representing their values during the build process.

Now if the published version of these components still includes the reference to the global variable, this is a bug in the build process of AtlasKit. But since it is not allowed to open Pull Requests for AtlasKit, and you will probably not manage within your lifetime to find anyone at Atlassian to fix this bug for you, you will have to implement a workaround yourself.

In case you are using webpack, webpack 5 removed native support for the process.env variable. You can find information about alternatives here and here.

In our case, we use webpack as a build tool and have the following in the plugins section of our webpack config:

        new webpack.DefinePlugin({
            'process.env': {
                ENV: devMode ? 'development' : 'production'

However, we are still on webpack 4, so I’m not sure this will work on webpack 5. I vaguely remember trying to upgrade to webpack 5 one day but reverting back to 4 because I ran into lots of trouble with AtlasKit.

1 Like

Thanks a lot Candid! You nudged me in the right direction. We are using Webpack 5, which stopped polyfilling the process variable.
So we’re going to bloat our build process some more ¯_(ツ)_/¯

1 Like

Hi guys,

I’ve just hit the same issue after upgrading to Webpack 5.
And then there’s another package @atlaskit/analytics-next that requires process.env.ANALYTICS_NEXT_MODERN_CONTEXT. So my first approach was the same as suggested by @candid with DefinePlugin, but later I found another solution which returns the process polyfill back:

a) add process dependency: npm i --save-dev process
b) add to webpack config

plugins: [
        new webpack.ProvidePlugin({
                // required by some @atlaskit components, but Webpack5 does not provide node.js polyfills anymore
                process: 'process/browser',

Just wanted to share. Hope it’ll help somebody not to waste a couple of hours like I did.


1 Like

Hi @shchagin,

yes, we also had this as the first solution. A really nice quick fix :slight_smile: .
The issue with that is that the polyfill only returns an empty object for the env property on the process object. That might work but it could also lead to unexpected behavior of the AtlasKit components. So depending on the env property that needs to be provided, you might want to give them some real values. Here the approach described by @candid is really helpful.

Cheers, Tino