Question related to console warning

[dahei]

This is related to #1029

We use grunt-env and grunt-browserify to bundle our build. Babel(ify) is used for transpiling.

When I create our production build, I set NODE_ENV via grunt-env to "production" . The resulting bundle gets also unglified afterwards.

The minified bundle is significantly smaller than without using grunt-env, so it seems, browserify is aware of the NODE_ENV and is building a "production" version.

Alls runs fine on our local servers. No warning in the js-console.

When building the same app via Jenkins on our staging-server (which just executes npm install and grunt), the resulting main.js leads to the warning introduced in #1029, while running in the browser.

As I log the process.env.NODE_ENV during the grunt build, I can also see, that it is "production". The bundled js File has the exact same size, as I would build it on my local machine.

So I am confused, what exactly this warning is all about. As far as I unterstand envify isn't really necessary -> http://stackoverflow.com/a/25752661/1574484

Why is the warning not on my local machine, although the same grunt build was applied?

Maybe someone could explain the backgrounds of this envify/NODE_ENV thing?

[gaearon]

So I am confused, what exactly this warning is all about. As far as I unterstand envify isn't really necessary -> http://stackoverflow.com/a/25752661/1574484

I don't think that answer is correct. You need to envify React, the docs explicitly mention this.

As I log the process.env.NODE_ENV during the grunt build, I can also see, that it is "production".

You are logging NODE_ENV of your Node environment. That doesn't mean that the generated code has correct NODE_ENV polyfilled. The point of envifying is to embed a string matching the current environment into the generated code. If you don't envify, sure, you'll run your build with NODE_ENV=production but the generated code won't contain it.

This is my guess anyway. You can try console.log(process.env.NODE_ENV) from your app’s code. If it’s not 'production', you are not envifying your build correctly.

[gaearon]

Seems like I was wrong and React does include transform field in its package: https://github.com/facebook/react/blob/0ce28c6e88448af6eda69df66088b88e7248bbb7/packages/react/package.json#L29-L33. Then we can do the same and hopefully you won't have to envify manually: #1301.

[dahei]

Thank's for your fast reply and your awesome work on redux!

This is my guess anyway. You can try console.log(process.env.NODE_ENV) from your app’s code. If it’s not 'production', you are not envifying your build correctly.

I tried that. When setting the env before browserify via grunt-env to "production", the output is actually "production". When I don't use grunt-env, it is undefined (as you expected)

My grunt browserify options are looking like this:

options : {
        extensions : [ '.jsx' ],
        transform : [
            [
                'babelify',
                {
                    presets : [ "es2015", "react" ],
                    plugins : [ "transform-object-rest-spread" ]
                }
            ],
            "envify"
        ]
    }

Unfortunately the warning is still there :(

which is the result of this console.log in my main.js

So any idea what I am doing wrong?

[Enet4]

My hunch is that the envify transform is not being applied as a global transform. This means envify would not transform dependency modules such as Redux.

Honestly, I am not quite sure how this would be configured (the docs don't seem to help), but according to what I found in an issue, this might work:

options : {
        extensions : [ '.jsx' ],
        transform : [
            [
                'babelify',
                {
                    presets : [ "es2015", "react" ],
                    plugins : [ "transform-object-rest-spread" ]
                }
            ],
            [
              'envify',
              {
                global: true
              }
            ]
        ]
    }

---

Well, a little more research suggests that a well configured package would also be transformed by envify, just as long as browserify is provided in the package.json. In that case, I'd better back off. No need for global.

[gaearon]

#1301 probably fixed this. We'll push this out in 3.1.

[dahei]

@Enet4

Yeah - you nailed it 👍 Thank you very much :)

It was the global flag, which was needed. Now it's all correctly envified. Learned a lot today!

[Enet4]

@dahei Indeed, the global flag is needed without the fix presented in #1301. Nevertheless, I haven't found a situation where globally envifying NODE_ENV is undesirable.

[dahei]

Yes, the fix in #1301 fixes the issue for redux, but from my perspective, still a major part of libs don't have this config and aren't aware of it.
So it is still a good practice to envify everything in future.