Using object property (imported from CommonJS / CJS package) as media query results in failed build

[dddlr]

Example:

import { media } from '@atlaskit/primitives/responsive';
import { css, styled, cssMap } from '@compiled/react';
import React from 'react';

const SummaryContainer = styled.div({
  [media.above.lg]: {
    color: 'blue',
  }
});

export const App = (): JSX.Element => (
  <>
    <SummaryContainer>Goodbye world?</SummaryContainer>
  </>
);

We expect this to work, because @compiled/babel-plugin runs a variety of functions specifically for resolving imported variables. However, we actually get a Cannot statically evaluate the value of "MemberExpression error.

This is because the function that finds exports in @atlaskit/primitives/responsive only looks for export statements in the form export { media } from './media-helper'; or perhaps export defaultExport from './test'. This fails with @atlaskit/primitives because there are no export statements to be found in the output, and so @compiled/babel-plugin cannot resolve the value of media.

We see in the above screenshot that what we expected to be export { media } from './media-helper' in TypeScript is in fact this boilerplate code in @atlaskit/primitives:

Object.defineProperty(exports, "media", {
  enumerable: true,
  get: function get() {
    return _mediaHelper.media;
  }
});
var _mediaHelper = require("./media-helper");

Some potential ways to fix this issue:

• Detect the CommonJS require and exports syntax, and add handling for this in the @compiled/babel-plugin resolver functions
  • Relevant: https://babeljs.io/docs/babel-plugin-transform-modules-commonjs
  • A naive approach would be to use Babel traversal to detect something that looks like Object.detectProperty(exports, ...), and use that to parse the value of media.
  • A more thorough approach would be to actually try to get the full value of the exports variable at the end of the file, but I'm not sure if we can do this with Babel traversals?
• Just don't support CommonJS packages
  • There may be other packages that use CommonJS that are outside our control. Doesn't seem like a viable option
• Ask the user to use a custom resolver (through the resolver option in .compiledcssrc, for example) that returns ESM build of packages, not CommonJS build

Currently the way we get around this problem is to use a custom resolver. ESM build of @atlaskit/primitives works without issues, as long as our custom resolver returns the ESM build not the CommonJS build.

Tested with @atlaskit/primitives v1.17.0 and @compiled/babel-plugin v0.28.2