Emotion: Invalid CSS output from function based dynamic styles

[Slapbox]

Current behavior:

Using an array of styles leads to invalid CSS properties in the DOM named label, name, and styles.

On the first style passed, the invalid CSS prop label does not appear in the DOM, but for subsequent styles it does. Additionally the first rule in the CSS in each style passed is nested invalidly like so: styles: color: red;

To reproduce:

Can't reproduce this issue on CodeSandbox - so possibly related to babel or webpack would be my guess. Does the order of babel plugins matter when including the emotion plugin? I get this issue whether I use the plugin or not.

Expected behavior:

No invalid props in the DOM and the first rule is not mangled and ignored.

Environment information:

• react version: 16.9.0
• emotion version: 10.0.17

[Andarist]

Have you been able to repro this on codesandbox? If yes - could you share a link?

[Slapbox]

I tried for an hour, but no. At this stage all I expect is to hopefully collect some more information or reports about this unless someone happens to have seen it before and knows a fix.

Unfortunately this occurs anywhere in my code I use a function based style, but identical code in CodeSandbox works fine. This is my babel config, since I can't think of anything else that might even possibly be the cause (besides webpack, but my configuration is pretty vanilla):

{
  "ignore": [
    "node_modules/",
  ],
  "presets": [
    ["@babel/preset-env", {
      "targets": { "electron": "6.0.0" },
      "useBuiltIns": "usage"
    }],
    "@babel/preset-react",
    "@babel/preset-flow"
  ],
  "plugins": [
    "@babel/plugin-transform-flow-strip-types",
    "add-module-exports",
    "@babel/plugin-proposal-export-default-from",
    ["@babel/plugin-proposal-optional-chaining", { "loose": false }],
    "@babel/plugin-proposal-do-expressions",
    "@babel/plugin-proposal-export-namespace-from",
    "@babel/plugin-proposal-class-properties",
    "@babel/plugin-transform-classes",
    "emotion"
  ],
}

I think CodeSandbox supports babel plugins (?) so I can give it another shot when I find some time.

[Andarist]

If you can't repro this on codesandbox a regular repository is acceptable as repro too - we just recommend codesandbox as it's easier to setup.

[Slapbox]

No luck reproducing, but this basically neuters Emotion since dynamic styles are off the table without a lot of hacky stuff like:

const activeStyles = props =>
  css`
    border: 0; //  Dummy rule to overcome Emotion bug
    color: ${props.active ? '#3b85a0' : 'white'};
    opacity: ${props.active ? '0.9' : '1'};
  `;

Any ideas at all would be appreciated. Not really sure what else we can do unfortunately since I haven't the faintest clue what the cause is and all my attempts to reproduce this fail. It's a 100% consistent issue in our environment, even when we start stripping away things like babel plugins and parts of the application.

Quick clip of the output styles when toggling the active props: https://recordit.co/qdxRlLHrIE

[Slapbox]

Order of the styles in the array doesn't seem to yield any difference in output as far as I can tell, only order of the improper rules and an extra leading name: style when using css based string interpolation.

There are differences between methods of creating the style object passed to the css prop array.

With css string interpolation based activeStyles

With an object for activeStyles:

[Slapbox]

Additionally when I just tried to remove this problematic component from my project temporarily, `styled.div``` which works perfectly and is for an entirely different component than the one with the problem suddenly and inexplicably begins to fail with:

Uncaught TypeError: Object(...)(...).withConfig is not a function

I was sure I must have a typo or syntax error, but after painstakingly checking and trying dozens of things, there's no issue in the code. I can't find any way to even remove this component with no ties to the rest but for being a child without hitting that error. I'm am truly confused.

Occurs with functional components and class-based.

[Slapbox]

@Andarist this isn't directly related to my original issue, but a typo I made resulted in a vaguely similar issue, although the cause is obvious here (a stray apostrophe.)

Is there any chance something similar to my typo this, but in Emotion's internals might be the cause of my original issue?

Input:

import styled from '@emotion/styled';

export const KeyboardStyled = styled.kbd`
  & + & {
    margin-left: 5px !important;
  }

  word-spacing: -1px;
  padding: 0.1em 0.6em;
  border: 1px solid #ccc;
  font-size: 11px;
  background-color: #f7f7f7;
  color: #333;
  box-shadow: 0 1px 0 rgba(0, 0, 0, 0.2), 0 0 0 2px #ffffff inset;
  border-radius: 2px;
  display: inline-block;
  margin: 0 0.125rem;
  text-shadow: 0 0px 0 rgba(0, 0, 0, 0.2);
  line-height: 1.5;
  white-space: nowrap;
  font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial,
    sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol';
`;

const RestyledKbd = styled(KeyboardStyled)`
    background: rebeccapurple;
    position: relative'; // <<<< Note the stray '
    top: -1;
    line-height: 1.4;
`;

Output CSS: (Note issues begin below rebeccapurple)

.css-15w1uz3-KeyboardStyled-RestyledKbd {
    word-spacing: -1px;
    padding: 0.1em 0.6em;
    border: 1px solid #ccc;
    font-size: 11px;
    background-color: #f7f7f7;
    color: #333;
    box-shadow: 0 1px 0 rgba(0,0,0,0.2), 0 0 0 2px #ffffff inset;
    border-radius: 2px;
    display: inline-block;
    margin: 0 0.125rem;
    text-shadow: 0 0px 0 rgba(0,0,0,0.2);
    line-height: 1.5;
    white-space: nowrap;
    font-family: -apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';
    background: rebeccapurple;
    position: relative'; top: -1; line-height: 1.4; /*# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbIkM6XFxwcm9qZWN0c1xccmVjb2xsZWN0clxcYXBwXFxkZXNrdG9wXFxjb21wb25lbnRzXFxOb3RlTGlzdFxcTm9Ob3RlSW5MaXN0LmpzIl0sIm5hbWVzIjpbXSwibWFwcGluZ3MiOiJBQU8wQyIsImZpbGUiOiJDOlxccHJvamVjdHNcXHJlY29sbGVjdHJcXGFwcFxcZGVza3RvcFxcY29tcG9uZW50c1xcTm90ZUxpc3RcXE5vTm90ZUluTGlzdC5qcyIsInNvdXJjZXNDb250ZW50IjpbImltcG9ydCBSZWFjdCBmcm9tICdyZWFjdCc7XG5pbXBvcnQgY3ggZnJvbSAnY2xhc3NuYW1lcyc7XG5pbXBvcnQgc3R5bGVkIGZyb20gJ0BlbW90aW9uL3N0eWxlZCc7XG5pbXBvcnQgeyBjc3MgfSBmcm9tICdAZW1vdGlvbi9jb3JlJztcbmltcG9ydCB7IEtleWJvYXJkU3R5bGVkIH0gZnJvbSAncmVjb2xsZWN0ci1jb21wb25lbnRzLWVsZWN0cm9uJztcbmltcG9ydCB7IGZvcm1hdEZ1dHVyZVRpbWUgfSBmcm9tICdyZWNvbGxlY3RyLXV0aWxzJztcblxuY29uc3QgUmVzdHlsZWRLYmQgPSBzdHlsZWQoS2V5Ym9hcmRTdHlsZWQpYFxuICBcbiAgICBiYWNrZ3JvdW5kOiByZWJlY2NhcHVycGxlO1xuICAgIHBvc2l0aW9uOiByZWxhdGl2ZSc7XG4gICAgdG9wOiAtMTtcbiAgICBsaW5lLWhlaWdodDogMS40OyAvLyAgQWxsIG5lZWRlZCB0byBmaXggbGluZSBoZWlnaHRcbmA7XG5cbi8vIGNvbnN0IHNwYW5QYXJ0aWFsID0gY3NzYFxuLy8gICBmb250LXNpemU6IDEycHg7XG4vLyAgIHRleHQtYWxpZ246IGNlbnRlcjtcbi8vICAgY29sb3I6ICM2NjY7XG4vLyBgO1xuXG5jb25zdCBOb05vdGVJbkxpc3RSb290ID0gc3R5bGVkKEJveClgXG4gIHBhZGRpbmc6IDFyZW07XG4gIGZsZXgtZ3JvdzogMTtcbiAgZGlzcGxheTogZmxleDtcbiAgZmxleDogMTtcbiAgZmxleC1kaXJlY3Rpb246IGNvbHVtbjtcbiAgd2lkdGg6IDEwMCU7XG4gIG1pbi13aWR0aDogMzAwcHg7XG4gIG1hcmdpbjogMDtcbiAgYmFja2dyb3VuZDogI2U3ZTdlNztcbiAgb3V0bGluZTogbm9uZSAhaW1wb3J0YW50O1xuICBib3gtc2hhZG93OiBpbnNldCAtMnB4IC0ycHggMjRweCAtM3B4IHJnYmEoMCwgMCwgMCwgMC41KTtcbiAgb3ZlcmZsb3cteDogaGlkZGVuO1xuICBvdmVyZmxvdy15OiBzY3JvbGw7XG5cbiAgKiB7XG4gICAgZm9udC1mYW1pbHk6IFJvYm90byAhaW1wb3J0YW50O1xuICAgIHRleHQtc2hhZG93OiBub25lICFpbXBvcnRhbnQ7XG4gIH1cblxuICBzcGFuIHtcbiAgICBmb250LXNpemU6IDEycHg7XG4gICAgdGV4dC1hbGlnbjogY2VudGVyO1xuICAgIGNvbG9yOiAjNjY2O1xuICAgIGxpbmUtaGVpZ2h0OiAxLjY1O1xuICAgIG1hcmdpbi1ib3R0b206IDAuMjVyZW07XG4gIH1cbmA7XG5cbmNvbnN0IE5vTm90ZVNlbGVjdGVkID0gc3R5bGVkLnNwYW5gXG4gIGZvbnQtc2l6ZTogMTZweCAhaW1wb3J0YW50O1xuYDtcblxuY29uc3QgV2hhdCA9IHN0eWxlZC5zcGFuYFxuICAvLyAke3NwYW5QYXJ0aWFsfVxuICBkaXNwbGF5OiBibG9jaztcbiAgbGluZS1oZWlnaHQ6IDIuMjUgIWltcG9ydGFudDsgLy8gICFpbXBvcnRhbnQgcmVxdWlyZWRcbiAgZm9udC1zaXplOiAxNHB4ICFpbXBvcnRhbnQ7IC8vICAhaW1wb3J0YW50IHJlcXVpcmVkXG4gIHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lO1xuYDtcbmNvbnN0IFdoZW4gPSBzdHlsZWQuc3BhbmBcbiAgLy8gJHtzcGFuUGFydGlhbH1cbiAgZm9udC1zdHlsZTogaXRhbGljO1xuICBmb250LXNpemU6IDEzcHg7XG4gIGxpbmUtaGVpZ2h0OiAyO1xuYDtcblxuY29uc3QgTm9Ob3RlSW5MaXN0ID0gcHJvcHMgPT4ge1xuICBjb25zdCB7XG4gICAgcGFyc2VkUmVtaW5kZXI6IHsgZGlydHlXaGF0LCB3aGF0LCB3aGVuIH0sXG4gICAgY2xhc3NlcyxcbiAgICBsb29rc0xpa2VBUmVtaW5kZXIsXG4gIH0gPSBwcm9wcztcbiAgY29uc3QgY2xhc3NMaXN0ID0gY3goJ25vTm90ZVNlbGVjdGVkRGl2JywgY2xhc3NlcywgeyBsb29rc0xpa2VBUmVtaW5kZXIgfSk7XG4gIHJldHVybiAoXG4gICAgPE5vTm90ZUluTGlzdFJvb3QgaWQ9XCJub05vdGVJbkxpc3RcIiBjbGFzc05hbWU9e2NsYXNzTGlzdH0+XG4gICAgICB7bG9va3NMaWtlQVJlbWluZGVyID8gKFxuICAgICAgICA8Q3JhZnRpbmdSZW1pbmRlciB7Li4ucHJvcHN9IC8+XG4gICAgICApIDogKFxuICAgICAgICA8Tm9TZWFyY2hNYXRjaGVzIHsuLi5wcm9wc30gLz5cbiAgICAgICl9XG4gICAgPC9Ob05vdGVJbkxpc3RSb290PlxuICApO1xufTtcblxuZXhwb3J0IGRlZmF1bHQgTm9Ob3RlSW5MaXN0O1xuXG5jb25zdCBDcmFmdGluZ1JlbWluZGVyID0gcHJvcHMgPT4ge1xuICBjb25zdCB7XG4gICAgcGFyc2VkUmVtaW5kZXI6IHsgZGlydHlXaGF0LCB3aGVuLCBwcmVwb3NpdGlvbiB9LFxuICB9ID0gcHJvcHM7XG4gIGNvbnN0IGludmVydGVkUG9zc2Vzc2l2ZVdoYXQgPSBkaXJ0eVdoYXRcbiAgICA/IGRpcnR5V2hhdC5yZXBsYWNlKC9eID9bSXx3ZV0gL2ksICcgeW91ICcpXG4gICAgOiAnJztcbiAgY29uc3QgcHJlcG9zaXRpb25Ub0Rpc3BsYXkgPSBkaXJ0eVdoYXQgPyBwcmVwb3NpdGlvbiA6ICcnOyAvLyAgSWYgd2UgZGlzcGxheSBhIHByZXBvc2l0aW9uIGl0IHdpbGwgbG9vayBsaWtlLCBcIlJlbWluZCBtZSB0byBeIEAgW1NvbWUgVGltZV1cIiAtLSBeIGlzIHdoZXJlIHdlIHNob3VsZCBoYXZlIGFuIGFjdGlvbiBcInRvXCIgZG8sIGJ1dCB3b3VsZG4ndFxuXG4gIC8vIGNvbnN0IHNwbGl0SW52ZXJ0ZWQgPSBpbnZlcnRlZFBvc3Nlc3NpdmVXaGF0LnRyaW0oKS5zcGxpdCgnICcpO1xuXG4gIC8vIGNvbnN0IHByZXBvc2l0aW9uID0gc3BsaXRJbnZlcnRlZC5zaGlmdCgpOyAvLyBJIGRvbid0IGtub3cgaWYgdGhpcyBpcyByZWFsbHkgYSBwcmVvcG9zaXRpb25cbiAgLy8gY29uc3QgZmluYWxXaGF0ID0gc3BsaXRJbnZlcnRlZC5qb2luKCcgJyk7XG5cbiAgY29uc3QgZm9ybWF0dGVkV2hlbiA9IGZvcm1hdEZ1dHVyZVRpbWUod2hlbik7XG4gIHJldHVybiAoXG4gICAgPHNwYW4+XG4gICAgICBQcmVzcyA8S2V5Ym9hcmRTdHlsZWQ+RW50ZXI8L0tleWJvYXJkU3R5bGVkPiB0byBjcmVhdGUgYSByZW1pbmRlclxuICAgICAge2AgJHtwcmVwb3NpdGlvbn0gYH1cbiAgICAgIDxXaGF0PntpbnZlcnRlZFBvc3Nlc3NpdmVXaGF0fTwvV2hhdD4gQCA8V2hlbj57Zm9ybWF0dGVkV2hlbn08L1doZW4+XG4gICAgPC9zcGFuPlxuICApO1xufTtcblxuY29uc3QgTm9TZWFyY2hNYXRjaGVzID0gcHJvcHMgPT4ge1xuICBjb25zdCB7IHNlYXJjaFRlcm0gfSA9IHByb3BzO1xuICByZXR1cm4gKFxuICAgIDxSZWFjdC5GcmFnbWVudD5cbiAgICAgIDxOb05vdGVTZWxlY3RlZD5ObyBNYXRjaGVzPC9Ob05vdGVTZWxlY3RlZD5cbiAgICAgIDxzcGFuPlxuICAgICAgICBQcmVzcyA8UmVzdHlsZWRLYmQ+RW50ZXI8L1Jlc3R5bGVkS2JkPiB0byBjcmVhdGUgYSBuZXcgbm90ZSB3aXRoIHRoZVxuICAgICAgICB0aXRsZTpcbiAgICAgIDwvc3Bhbj5cblxuICAgICAgPFdoYXQgY2xhc3NOYW1lPVwid2hhdFwiPntzZWFyY2hUZXJtfTwvV2hhdD5cbiAgICA8L1JlYWN0LkZyYWdtZW50PlxuICApO1xufTtcbiJdfQ== */;}/*# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbIkM6XFxwcm9qZWN0c1xccmVjb2xsZWN0clxccGFja2FnZXNcXGVsZWN0cm9uXFxyZWNvbGxlY3RyLWNvbXBvbmVudHMtZWxlY3Ryb25cXHNyY1xcdGV4dFxcS2V5Ym9hcmRTdHlsZWQuanMiXSwibmFtZXMiOltdLCJtYXBwaW5ncyI6IkFBRXdDIiwiZmlsZSI6IkM6XFxwcm9qZWN0c1xccmVjb2xsZWN0clxccGFja2FnZXNcXGVsZWN0cm9uXFxyZWNvbGxlY3RyLWNvbXBvbmVudHMtZWxlY3Ryb25cXHNyY1xcdGV4dFxcS2V5Ym9hcmRTdHlsZWQuanMiLCJzb3VyY2VzQ29udGVudCI6WyJpbXBvcnQgc3R5bGVkIGZyb20gJ0BlbW90aW9uL3N0eWxlZCc7XG5cbmV4cG9ydCBjb25zdCBLZXlib2FyZFN0eWxlZCA9IHN0eWxlZC5rYmRgXG4gICYgKyAmIHtcbiAgICBtYXJnaW4tbGVmdDogNXB4ICFpbXBvcnRhbnQ7XG4gIH1cblxuICB3b3JkLXNwYWNpbmc6IC0xcHg7XG4gIHBhZGRpbmc6IDAuMWVtIDAuNmVtO1xuICBib3JkZXI6IDFweCBzb2xpZCAjY2NjO1xuICBmb250LXNpemU6IDExcHg7XG4gIGJhY2tncm91bmQtY29sb3I6ICNmN2Y3Zjc7XG4gIGNvbG9yOiAjMzMzO1xuICBib3gtc2hhZG93OiAwIDFweCAwIHJnYmEoMCwgMCwgMCwgMC4yKSwgMCAwIDAgMnB4ICNmZmZmZmYgaW5zZXQ7XG4gIGJvcmRlci1yYWRpdXM6IDJweDtcbiAgZGlzcGxheTogaW5saW5lLWJsb2NrO1xuICBtYXJnaW46IDAgMC4xMjVyZW07XG4gIHRleHQtc2hhZG93OiAwIDBweCAwIHJnYmEoMCwgMCwgMCwgMC4yKTtcbiAgbGluZS1oZWlnaHQ6IDEuNTtcbiAgd2hpdGUtc3BhY2U6IG5vd3JhcDtcbiAgZm9udC1mYW1pbHk6IC1hcHBsZS1zeXN0ZW0sIEJsaW5rTWFjU3lzdGVtRm9udCwgJ1NlZ29lIFVJJywgSGVsdmV0aWNhLCBBcmlhbCxcbiAgICBzYW5zLXNlcmlmLCAnQXBwbGUgQ29sb3IgRW1vamknLCAnU2Vnb2UgVUkgRW1vamknLCAnU2Vnb2UgVUkgU3ltYm9sJztcbmA7XG4iXX0= */;
}

[Andarist]

Is there any chance something similar to my typo this, but in Emotion's internals might be the cause of my original issue?

This is doubtful - like maybe there is some combination of things that is not handled properly, but it has to be a rather different thing because we just don't insert stuff into what you write yourself (except source maps & labels, but they always come last so shouldnt affect any styles I think)

[Slapbox]

I noticed it seems to be the first rule of css that's ignored in _any_ circumstance. Here's another scenario:

Input:

const activeStyles = props =>
  props.active  &&
  css`
    border: none; //  Dummy rule to overcome Emotion bug -- https://github.com/emotion-js/emotion/issues/1524

    && {
      color: #3b85a0;
      opacity: 1;
    }
  `;

Output:

.bBHyQG {
    name: 1lffm4s;
    styles: border:none;
}

.bBHyQG.bBHyQG {
    color: #3b85a0;
    opacity: 1;
}

[Andarist]

can you provide a codesandbox for your last case?

[MMT-LD]

I noticed it seems to be the first rule of css that's ignored in _any_ circumstance. Here's another scenario:

Input:

const activeStyles = props =>
  props.active  &&
  css`
    border: none; //  Dummy rule to overcome Emotion bug -- https://github.com/emotion-js/emotion/issues/1524

    && {
      color: #3b85a0;
      opacity: 1;
    }
  `;

Output:

.bBHyQG {
    name: 1lffm4s;
    styles: border:none;
}

.bBHyQG.bBHyQG {
    color: #3b85a0;
    opacity: 1;
}

Not sure if this helps.... but.... i have seen this happen when you don't close off the css selectors correctly. I have had a few examples of this happen over time and i have to really look deep into the css and see if i have not forgotten to add a semi-colon at the end of the css selectors. Otherwise i get the name issue as you are explaining.

for example:

css`
    ${test && `background:red`}
    color: green;
`

would output the css concatenated. But this would be ok....

css`
    ${test && `background:red;`}
    color: green;
`

[Slapbox]

@Andarist I took a crack at it, but I feel like I must have done something wrong here? https://codesandbox.io/s/emotion-issue-template-r2peb

The code's very simple and mirrors what works in my development environment (albeit with a bug) - but I can't get any effect to occur here. As far as I or ESLint can tell, I haven't screwed anything.

At the line const activeStyles = props => - props is an empty object?

Some other weirdness I noticed:

On my local machine:

css={[activeStyles]}  // Works with aforementioned bug - No console messages

css={activeStyles} // Console: Uncaught ReferenceError: Cannot access 'activeStyles' before initialization -- It should definitely be initialized based on my understanding

On CodeSandbox:

css={[activeStyles]} // Does not work at all - Console: Functions that are interpolated in css calls will be stringified.

css={activeStyles} // Does not work at all - No console messages

Edit: I realized Emotion and React were at different versions than mine and I was importing css differently. I updated the sandbox, but behavior is identical.

[MMT-LD]

@Slapbox https://codesandbox.io/s/emotion-issue-template-q39hk - does this help?

[Andarist]

function interpolated into styled receives props as argument, but when used as value of css prop it gets a theme object (not props). It doesn't make sense for us to do work to merge theme with props as with css prop you already have access to props because you define your css prop inside render - and that isn't true for styled API.

As to css={[activeStyles]} - we only add theme consumer internally if you provide a function to css prop, as you have provided an array we don't do that automatically and if you need to access theme in such a situation you should do this:

css={theme => [activeStyles(theme)]} 

[FezVrasta]

We do have this bug about semi colons

https://github.com/emotion-js/emotion/issues/1284

[Slapbox]

@Andarist thanks for your explanation about theme consumption.

I am pretty confused about not being able to access props though, because that's exactly what I'm able to do. Am I misunderstanding what you mean? I can't understand why I can't replicate this behavior in CodeSandbox, regardless of whether this is how the library _should_ be used.

We're using the pinnedStyles partial like so:

const Button = styled.button`
  padding: 5px;
`;

render () {
  return (
    <Button
      alwaysOnTop={props.alwaysOnTop}
      css={[pinnedStyles]}
    />
  )
}

Thanks @MMT-LD for that CodeSandbox. I was trying to break things in a very particular way though - which either because I'm misunderstanding something or perhaps because of differences in build environment I'm not able to because the behavior of the sandbox versus my project seems to be quite different.

No missing semicolons in any areas I'm seeing this bug.

[Slapbox]

I just discovered this occurs for me as well. Unlike my other findings, this one can be replicated in CodeSandbox

Keyframes work:

Input:

export const StyledRoot = styled.div`  
  animation: ${fadeOutB} 10s;
`

Output:

    -webkit-animation: animation-1oltsgd 10s;
    animation: animation-1oltsgd 10s;

Conditional keyframes fail:

Input:

export const StyledRoot = styled.div`  
  ${props => props.animate && `
    animation: ${fadeOutB} 10s;
  `}
`

Output:

  _EMO_ 10s: ;

Additional relevant code:

import { keyframes } from '@emotion/core';
const fadeOutB = keyframes`
  0% {
    opacity: 1;
  }

  8% {
    opacity: 0.8;
  }

  15% {
    opacity: 0.6;
  }

  100% {
    opacity: 0;
  }
`;

[Andarist]

Thanks for the sandbox - gonna investigate this some time later.

[Andarist]

I am pretty confused about not being able to access props though, because that's exactly what I'm able to do. Am I misunderstanding what you mean? I can't understand why I can't replicate this behavior in CodeSandbox, regardless of whether this is how the library should be used.

Put a debugger in there and check out the stack trace to see what gives you that props argument.

Regarding keyframes stuff - for now you should wrap it with css. We are going to either allow interpolating keyframes output into plain strings or introduce a dev warning about misusing it. See https://github.com/emotion-js/emotion/pull/1553 .

Interpolating into strings:

const str = `${keyframes()}`

and into tagged template calls

const str = css`${keyframes()}`

is a different thing, although they look pretty much similar. With tagged templates we receive what you actually put in there, but with a plain string the interpolated value gets stringified by JavaScript.

[Slapbox]

Thanks as always for the tip @Andarist!

I pulled up the stack trace, but I see styled-components and not emotion in the call stack... is this normal? If not, I can't imagine why it would be using styled-components since it's not imported or referenced anywhere in that file, although it is present in the project as a dependency of a dependency.

[Andarist]

I pulled up the stack trace, but I see styled-components and not emotion in the call stack... is this normal?

Nope, we don't depend anyhow on styled-components.

If not, I can't imagine why it would be using styled-components since it's not imported or referenced anywhere in that file, although it is present in the project as a dependency of a dependency.

Maybe it's somehow inserted by some babel plugin? Just a wild guess.

[Slapbox]

Indeed it looks like a styled-components babel plugin was in a nested .babelrc and it was passing props to my style partials. Pretty crazy side effect.

So the only real bug here will be addressed by #1553

I don't suppose there's any easy way to detect that the styled-components plugin is in use from emotion's side? It's not really within the scope of the project, but if it would be possible and easy, perhaps it would be worth it in the interest of preventing future issues like this from gunking up the issue tracker.

Thanks for your patience and assistance @Andarist.

[Andarist]

Unfortunately, nothing comes to my mind as to what we could do to warn about smth like this.

[Dajust]

Just encountered this problem while migrating from v9 to v11. Removing emotion from babel plugins fixed it for me as I already have @emotion/babel-preset-css-prop in babel presets.