Remove the warning spam

[dzearing]

This needs to either be avoided by not registering illegal rules, or by not logging the warning.

whoops, illegal rule inserted @-o-keyframes animation_do0sdn{from{opacity:0;}to{opacity:1;}}
_insert @ :4321/demo-app.js:19009
:4321/demo-app.js:19009 whoops, illegal rule inserted @-moz-keyframes animation_1igtztk{from{opacity:1;}to{opacity:0;}}
_insert @ :4321/demo-app.js:19009
:4321/demo-app.js:19009 whoops, illegal rule inserted @-o-keyframes animation_1igtztk{from{opacity:1;}to{opacity:0;}}

From a consumer's perspective there's nothing that can be done here, so these warnings are just noise.

Coming from this code:

    try {
      var sheet = this.getSheet();
      sheet.insertRule(rule, rule.indexOf('@import') !== -1 ? 0 : sheet.cssRules.length);
    } catch (e) {
      if (isDev) {
        // might need beter dx for this 
        console.warn('whoops, illegal rule inserted', rule); //eslint-disable-line no-console
      }
    }

Ideally we wouldn't be trying to register illegal rules. It is useless trying to register -o or -ms prefixed rules on Chrome, for example.

But shy of doing the browser detection and filtering, if there were another flag on glamor to suppress this, that would also work. But I really don't want to just force prod builds always just to remove this spam. It pollutes the warnings significantly.

[dzearing]

I'll be happy to submit a small PR, if you all have some guidance here. Remove the warning? Add another flag? Add a programatic way to override the isDev setting that can operate separately from depending on process.env.NODE_ENV to be defined

[threepointone]

Fwiw, this warning only shows up once, and not in production. Not sure what a good fix for this is yet... not use the default prefixer for key frames mybe?

[dzearing]

To experience the nastiness you can take a look at the console log here:

https://codepen.io/dzearing/pen/EgqMZq

Right now fabric styling takes a dependency on glamor, so it would be up to the consumer to bundle. But we can't guarantee that they're using webpack to bundle. Many people are still on amd bundling, so I'm a bit unsure how to best proceed. One idea I was playing with was to just make a custom bundle for glamor that does the define NODE_ENV production, and produces an amd exported single file bundle. (maybe using rollup.) Then refer to that file rather than the glamor node library directly.

[lrecknagel]

As temp fix with the console search input you can type the following to hide those messages:

/^(?!.*?whoops)/

... no the final solution but better than the overfloating logs.

[dzearing]

I can definitely work around the spam in a number of ways; but ideally a consumer using the api surface correctly should not see these. Right now it always happens.

[threepointone]

going to close this, can't think of a clean workaround just yet, and it doesn't affect in prod. feel free to reopen if new info comes to light.