React Invariant Violation / Minified Exception on iOS 8 with Webpack + Babel

TL;DR

Check out this gist to see the bug.

I ran into a head-scratcher over the weekend that I needed document, because I spent a few more hours than I wanted to trying to see why a deployed project wasn't working at all on iOS 8.4.

My project is using react, webpack, and babel. One of the babel plugins I'm using is babel-plugin-transform-react-inline-elements which transforms react elements to increase performance in production.

I'm also using the babel-polyfill (which includes the core-js shim) to polyfill some features like Symbols.

The project was working fine locally on iOS 8, but when deployed I was getting an error from react:

Error: Minified exception occurred; use the non-minified dev environment for the full error message and additional helpful warnings.

If I removed the babel-polyfill, the error went away. The problem was I needed the babel-polyfill especially on iOS 8 where there is no Symbol. I also tried just loading core-js/shim or just core-js/es6/symbol but the error was still happening. Here's a way stripped down version of my main JS file which was causing the error:

// The error goes way with no polyfill, but I need the polyfill
import 'babel-polyfill';

import React from 'react';
import DOM from 'react-dom';

DOM.render(
  <div>hey everybody</div>,
  document.getElementById('root')
);

Next, I removed the webpack define plugin so it was no longer replacing process.env.NODE_ENV so I could see what the unminified error was:

Invariant Violation: ReactDOM.render(): Invalid component element. This may be caused by unintentionally loading two independent copies of React.

I had a feeling that I wasn't actually loading two different copies of react, so I kept digging. It was then that I remembered I had some babel plugins turned on in production only. My .babelrc looked like this:

{
  "presets": [
    "react",
    "es2015"
  ],
  "env": {
    "production": {
      // Yay! Removing this plugin fixes it!
      "plugins": [
        "transform-react-inline-elements"
      ]
    }
  }
}

Once I disabled the transform-react-inline-elements plugin the error went away. Since this plugin is only used for performance improvements, I decided that working on iOS 8 was more important.

I put together a full gist of the bug to make it easier to reproduce. I still don't know exactly why this error is happening, but I plan on trying to report it to the relevant projects to see if it can be tracked down and fixed. The main lessons I learned though:

  • Remove process.env.NODE_ENV overwriting from your webpack bundle so you can see the error messages from react. See the DefinePlugin docs for more info
  • Babel environment specific plugins can lead to environment specific bugs. Always turn these off as a first step to debugging a production only bug.

Greenkeeper

Over the course of ~36 hours last weekend greenkeeper notified me of two of my projects where the build was broken by minor updates to tools that I was using.

Here is one of the nice PRs, from what is quickly becoming one of my favorite services:

One was a bug in a babel plugin that I use to treeshake my lodash methods to decrease the overall bundle size, and the other was a change to eslint that broke babel-eslint.

While it's kind of a bummer to get emails that your projects can't build right now due to changes you didn't make it, that is more than offset by knowing about it almost so quickly and being able to easily pin the dep to the previous working version.

In the case of babel-plugin-lodash greenkeeper notified my in less than 8 minutes (!!), and I was able to fix my project, go to the module's repo, find out that the issue wasn't reported yet, come up with test case to reproduce the bug only in the latest version, and hopefully save other developers time in tracking down the issue.

But my favorite part is now that I have a few projects with pinned dependencies, greenkeeper will then notify me of the next update to the package and see if my software is working again. If it is working, all I have to do is merge the pull request and I'm back on the latest version knowing that my software is working as it did before.

I now have greenkeeper enabled on 6 of my bigger open source projects, and it would be a no brainer to pay for to use on private projects.

Update 08 Mar 2016

Greenkeeper opened a PR 4 minutes and 27 seconds after babel-plugin-lodash was published and then a little bit later my CI tests on Travis notified me that the build from the PR was passing. I had to make one small change to set the version back to a range, since greenkeeper assumes you always want to keep the same type of version declaration (which is the desired behavior in most other cases).

Thanks again Greenkeeper!

npm@3: What Ends Up at the Top of node_modules with Conflicting Dependencies?

npm@3 has been stable for a few months now and one the big changes was the new flat(ter) directory structure inside node_modules. This blog post has a good writeup of why that's a good thing.

You'll notice that I said "flat(ter)" above. If two modules in your project have conflicting dependencies, then one of those will end up on the top level of node_modules and the other will be nested inside its parent's node_modules directory. This got me to wondering, which ones ends up on the top level?

I was wondering this because of a discussion on the eslint issue tracker about if the new directory structure will allow you to require a nested dependency now that it is at the top level of node_modules. As the linked comment pointed out, it will let you, but that doesn't mean you should do it. If you did depend on this functionality, you would be requiring a module without any guarantee of what version you would be getting back.

Read more

Secret Santa over SMS with Twilio

TL;DR

Use this code to pick Secret Santas over SMS with Twilio.

My family does a sibling Secret Santa (plus spouses) every year. We live in a few different cities, and we forgot to do it on Thanksgiving so we were out of luck as far as picking in person. My sisters know what I do for a living so they joked over text that I should "write a code". (Software is truly eating the world.)

I knew there were services out there to do remote Secret Santa, but they were all over email. I knew everyone's phone number and I knew that they would check their texts far more often than their email, so I really wanted something to deliver the recipients over SMS.

I found a Ruby script out there to do the same thing, but I wanted some additional logic and its been a few years since I wrote Ruby, plus I've always wanted to play around with Twilio. Sounds like a recipe for a nice Saturday project.

Read more

ES6 Arrow Function Stack Traces

Since I started writing ES6, I've adopted the functions without function approach and have quite liked it.

I'm not going to get into every reason why, but that post does a good job of echoing my thoughts on it. I'm not going so far as to say "never", but I don't think I've found the need to type the word function even once since I started writing ES6.

I have always wondered about stack traces when using arrow functions though.

Read more