Console Warnings on every component mount

[sudogoku]

I'm seeing this console warning on every React component (and subcomponent) mount that is importing a CSS module. There is no error and everything is rendering as expected, yet every mount and update from every component importing a CSS module generates this warning!

@@toStringTag : CSS module class not found in {{project path to .css file}}
app.js?hash=44f40ac753b63ca4a8646babe5096ca49669a9f9:4931

When you view the bundled js through dev tools, it appears the warning is coming from this section of the generated module.css.js file.

get: function (target, name) {
return name in target ? target[name] : console.warn(name, ': CSS module class not found in imports/ui/pages/dataTable.css');
}

This project is running Meteor 1.6.1, no added PostCSS plugins, React v16 (with some old Blaze templates), and React Router v4.

[akanix42]

The latest version of CSS modules alerts you if you attempt to reference a class that doesn't exist. It appears that React or one of your plugins is attempting to reference the non-existent @toStringTag property on the style import. You can disable the warning; see the changelog for more info: https://github.com/nathantreid/meteor-css-modules/blob/master/CHANGELOG.md#added

On Feb 18, 2018 2:45 AM, "Paul DiLoreto" notifications@github.com wrote:

I'm seeing this console warning on every React component (and subcomponent) mount that is importing a CSS module. There is no error and everything is rendering as expected, yet every mount and update from every component importing a CSS module generates this warning!

@toStringTag : CSS module class not found in {{project path to .css file}} app.js?hash=44f40ac753b63ca4a8646babe5096ca49669a9f9:4931

This project is running Meteor 1.6.1, no added PostCSS plugins, React v16 (with some old Blaze templates), and React Router v4.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nathantreid/meteor-css-modules/issues/115, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLBNo1MpxO-PDfqUHqBNGDa7qKFfD-Jks5tV-MVgaJpZM4SJnbD .

[sudogoku]

Thanks for the response! I see. I thought thats what that get function was doing, but I didn't consider that something was trying to use a @@toStringTag property.

Maybe it's React, like you said? Or could it be that a few of my CSS modules use @import. Do you think this could be causing the issue?

I will try removing it later today and post my results here.

[sudogoku]

Hey, just found what was causing the problem. As you suggested, it was a React-related dependency causing this console warning issue. Specifically, it is react-router-dom in React Router v4 that uses the function isSymbol when checking props for each component

This happens whenever we pass a CSS module as a 'theme' prop for React Toolbox.

function isSymbol(propType, propValue) {
    // Native Symbol.
    if (propType === 'symbol') {
      return true;
    }

    // 19.4.3.5 Symbol.prototype[@@toStringTag] === 'Symbol'
    if (propValue['@@toStringTag'] === 'Symbol') {
      return true;
    }

    // Fallback for non-spec compliant Symbols which are polyfilled.
    if (typeof Symbol === 'function' && propValue instanceof Symbol) {
      return true;
    }

    return false;
  }

This is particularly noticeable when rendering an input component that updates its value onChange. For every key press we get a console warning for every component that was updated.

I guess for now, my best bet is to revert to version 3.0.1 before this console warning was added?

[sudogoku]

Reverting to 3.0.1 resolves this issue for now. I'll close this.

[arggh]

@nathantreid Just wanted to let you know, that after updating to latest CSS-Modules 3.1.0, my browser console is being bombarded by these same error messages Symbol(Symbol.toStringTag) ": CSS module class not found in client/components/common/connection_lost/connection_lost.m.css"

It's caused by ViewModel, which upon the initialization of a new ViewModel instance, tries to determine the type for all of it's props (...or so I think after a quick glance at the source code). That determination of types is done with Underscore's _.is[Something]-methods, which make comparisons like this:

return toString.call(obj) == '[object ' + name + ']';

Apparently this clashes with addMissingStylesHandler of CSS-Modules, since the stylesJson in development mode is actually a proxy.

The warnings go away by disabling missingClassErrorLevel which effectively also disable the proxy from being used. If there's no easy fix for the issue, maybe it could be made clearer in the docs, that you can set missingClassErrorLevelto false and disable the Proxy (+ warnings) altogether?

[akanix42]

I expect this is rather simple to detect and fix, but I unfortunately haven't had time to do so yet. Hopefully I'll get to it this next week.

[akanix42]

This should be fixed in v3.1.2. I've also added a configurable option missingClassIgnoreList to exclude other properties as necessary. See the release notes for more info. Hopefully soon I'll get this added to the documentation as well. Please let me know if you still see error messages, and if possible provide a reproduction repo! I had to add some extra handling for the Vue devtools, and I'll be happy to do the same for React.

[arggh]

@nathantreid

I updated to v3.1.2, and now I can't build my app:

   Linking                                   /
<--- Last few GCs --->

[54319:0x102801600]   174954 ms: Mark-sweep 1274.1 (1457.8) -> 1274.0 (1457.8) MB, 669.4 / 0.2ms  allocation failure GC in old space requested
[54319:0x102801600]   175714 ms: Mark-sweep 1274.0 (1457.8) -> 1274.0 (1423.8) MB, 760.2 / 0.2ms  last resort GC in old space requested
[54319:0x102801600]   176327 ms: Mark-sweep 1274.0 (1423.8) -> 1273.9 (1420.8) MB, 613.3 / 0.1ms  last resort GC in old space requested

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x13d7e57257c1 <JSObject>
    0: builtin exit frame: stringify(this=0x13d7e5708ff1 <Object map = 0x13d70bc82ba1>,0x13d70d9022d1 <undefined>,0x13d70d9022d1 <undefined>,0x13d7104bc129 <JSArray[1]>)

    1: arguments adaptor frame: 1->3
    2: _linkJS [/Users/arggh/.meteor/packages/meteor-tool/.1.6.1_1.1up4o0m.3q4f++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/tools/isobuild/compiler-plugin.js:1402] [bytecode=0x13...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
Abort trap: 6

I'm running Meteor v1.6.1.1.

[arggh]

Downgrading back to v3.1.0 and all works fine.

[akanix42]

@arggh Yikes! That's an interesting error... you wouldn't happen to be able to provide a reproduction, would you? I didn't make that many changes between 3.1.0 and 3.1.2, so my guess is it's either 86050ab4b203bd4f1a5d7b4498b0b418af8f2280 or 596107ed68f0e31359b784abfbefb306ce4618cb.

Are you using SCSS syntax or composes in your project?

[akanix42]

It also might be related to this issue: https://github.com/meteor/meteor/issues/9568. One of the workarounds is to run the Meteor process with this environment variable set: TOOL_NODE_FLAGS="--max-old-space-size=4096". Max old space is an amount in megabytes of RAM, so upping it may work around the issue.

[arggh]

I use composes heavily, also I have lots of legacy SCSS files and fourseven:scss package installed for those, should that give you any ideas about the cause.

I'll try the node flag & also if I can isolate the cause (maybe fourseven:scss?) and build a repro if necessary.

[akanix42]

I just published 2 prerelease versions to help isolate this: 1: nathantreid:css-modules@3.1.3-gc-crash-1.1 reverts 596107ed68f0e31359b784abfbefb306ce4618cb. 2: nathantreid:css-modules@3.1.3-gc-crash-2.1 reverts 86050ab4b203bd4f1a5d7b4498b0b418af8f2280.

If you have time, please try them out and let me know if you still experience the issue.

The SCSS question was more about if you were using the SCSS processor that's built into the css-modules package. Since you're not, that shouldn't have an effect.

[arggh]

Sorry, I completely dropped the ball with this one and just forgot.

I now tried out both versions, and they both produce the same end-result.

However, running 3.1.2 with TOOL_NODE_FLAGS="--max-old-space-size=4096" does work. The build process seems to take quite long and it seems quite stuck at times, but in the end the app started.

[arggh]

After the first initial succesful build with 3.1.2, the build time seems to have normalized.

[arggh]

Also, after the first initial succesful build, I can skip passing the TOOL_NODE_FLAGS env var and the build succesfully completes.