Static properties on components break tree-shaking

[mbrowne]

In our app we are finding that any time a component that uses styled-components has a static property added to it, that component is always included in the bundle even if it's not imported, i.e. tree shaking does not work. For example:

const Wrapper = styled.div`
    color: blue;
`

function MyComponent() {
    return <Wrapper>hi</Wrapper>
}
// this breaks tree-shaking
MyComponent.displayName = 'Foo'

In some cases we're able to remove the displayName or use default function argument values instead of defaultProps, but there are other cases where we do need to use these properties.

This seems to be caused by the way terser (or uglify-js) removes dead code and isn't really an issue in babel-plugin-styled-components per se, but it would be great if babel-plugin-styled-components could include an option to address this.

[mbrowne]

UPDATE 8/30/19:
It turns out that I was using the PURE annotations incorrectly (as explained to me here). I updated my Babel plugin to use an IIFE to wrap the static properties instead:
https://github.com/mbrowne/babel-plugin-pure-static-props

Example output:

const MyComponent =
/*#__PURE__*/
function () {
  function MyComponent() {
    return _react.default.createElement(Wrapper);
  }
  MyComponent.displayName = 'Foo';
  return FunctionComponent;
}();

---

Here are some more details:

As with styled itself, it seems the best way to correct this problem is to add /*#__PURE__*/ comments to the code. (I suppose uglify-js must be worried that setting a static property could have side effects, e.g. if that property had a setter function.) Unfortunately, 'pure' annotations seem to be ignored for assignments and only work for function calls. But changing it to Object.assign() works:

/*#__PURE__*/
Object.assign(MyComponent, { displayName: 'Foo' })

I wrote a Babel plugin to test this out and verify that it works:
https://github.com/mbrowne/babel-plugin-pure-static-props

I tested it on our app, but didn't write unit tests for it yet because I wanted to share it here first...while it would be possible to solve this with a separate Babel plugin, I think it would be better if this functionality were part of babel-plugin-styled-components. BTW, my plugin isn't actually checking that styled-components is used; it just applies this transformation to all React components since I figured there was no reason not to (perhaps there are other edge cases that would also cause static properties to break tree-shaking).

Also, I did run into an issue with Rollup... Let me back up first and explain that we have a library for reusable UI components that we're importing from our app. We want the tree-shaking to happen in our app so that if we import only some of the library components, only those components are included in the bundle. We are building the library with rollup. The problem is that by default, rollup completely removes the Object.assign() statements from the code, e.g. it would remove this line:

/*#__PURE__*/
Object.assign(MyComponent, { displayName: 'Foo' })

There is a workaround though: rollup allows you to turn off this feature by adding this to the config:

    treeshake: {
        annotations: false,
    },

(Or you can pass --no-treeshake.annotations at the command line.)

[mxstbr]

This is very interesting, thank you for digging into this! 🙏

A PR that makes adds the IIFE wrapper (next to the PURE comment) when setting pure: true would be much appreciated, I definitely think the Babel plugin should be doing whatever it can to make tree shaking possible.

[mbrowne]

Great, glad you are open to including this. I can probably work on a PR for this sometime in the next week or two.

[mxstbr]

Amazing, can't wait @mbrowne! 🙏

[mbrowne]

For anyone who's interested, I created a test repo so that others can easily reproduce this issue, and also so that we have something to test against to ensure that my PR (when it's ready) covers all the bases:
https://github.com/mbrowne/CRA-error-template/tree/styled-components-tree-shaking
(be sure to check out this specific branch)

If you run yarn build on my demo, you can see that only Component1 tree-shakes correctly. (Earlier I thought that even that would break, because it seemed like this issue was affecting all of our library components, but fortunately in that simple case it's already working correctly.)