rxaviers / react-globalize-webpack-plugin

react-globalize webpack plugin
Other
3 stars 8 forks source link

Reference Error: `_` is not defined (StackTrace) #24

Closed zedd45 closed 2 months ago

zedd45 commented 7 years ago

I added some code with a recent commit, and Globalize Compiler will no longer complete a production build.

Unfortunately, the error seems a bit cryptic for me to decipher. I tried searching this repo and it's predecessor (rxaviers/globalize-webpack-plugin) for ReferenceError or another sign of this problem, but it looks like that message may be coming from a dependency, or I was simpy unable to turn up results as I expected.

The error I'm getting tells me _ isn't defined, but doesn't go into detail about where this error actually originates from in the code. I'm a bit stumped, and I've started removing the code from the commit (rolling back to the previous commit fixes it), but I've not had much success with this method, either.

Here's the error:

Populated the new fields of `messages/zh-Hant.json` using the default translation.
ReferenceError: _ is not defined
    at eval (eval at extractor (~/Sites/esports-ui/node_modules/react-globalize-compiler/lib/extract.js:65:10), <anonymous>:3:35)
    at ~/Sites/esports-ui/node_modules/globalize-compiler/lib/compile-extracts.js:59:23
    at Array.reduce (native)
    at Object.compileExtracts (~/Sites/esports-ui/node_modules/globalize-compiler/lib/compile-extracts.js:58:49)
    at GlobalizeCompilerHelper.compile (~/Sites/esports-ui/node_modules/globalize-webpack-plugin/GlobalizeCompilerHelper.js:63:33)
    at ~/Sites/esports-ui/node_modules/globalize-webpack-plugin/ProductionModePlugin.js:236:51
    at RegExp.[Symbol.replace] (native)
    at RegExp.[Symbol.replace] (native)
    at String.replace (native)
    at ~/Sites/esports-ui/node_modules/globalize-webpack-plugin/ProductionModePlugin.js:230:58
    at Array.forEach (native)
    at ~/Sites/esports-ui/node_modules/globalize-webpack-plugin/ProductionModePlugin.js:227:63
    at Array.forEach (native)
    at Compilation.<anonymous> (~/Sites/esports-ui/node_modules/globalize-webpack-plugin/ProductionModePlugin.js:225:10)
    at Compilation.applyPlugins (~/Sites/esports-ui/node_modules/tapable/lib/Tapable.js:26:37)
    at Compilation.<anonymous> (~/Sites/esports-ui/node_modules/webpack/lib/Compilation.js:558:8)
    at Compilation.next (~/Sites/esports-ui/node_modules/tapable/lib/Tapable.js:67:11)
    at ExtractTextPlugin.<anonymous> (~/Sites/esports-ui/node_modules/extract-text-webpack-plugin/index.js:285:5)
    at ~/Sites/esports-ui/node_modules/extract-text-webpack-plugin/node_modules/async/lib/async.js:52:16
    at Object.async.forEachOf.async.eachOf (~/Sites/esports-ui/node_modules/extract-text-webpack-plugin/node_modules/async/lib/async.js:236:30)
    at Object.async.forEach.async.each (~/Sites/esports-ui/node_modules/extract-text-webpack-plugin/node_modules/async/lib/async.js:209:22)
    at ExtractTextPlugin.<anonymous> (~/Sites/esports-ui/node_modules/extract-text-webpack-plugin/index.js:237:10)
    at Compilation.applyPluginsAsync (~/Sites/esports-ui/node_modules/tapable/lib/Tapable.js:71:13)
    at Compilation.seal (~/Sites/esports-ui/node_modules/webpack/lib/Compilation.js:525:7)
    at Compiler.<anonymous> (~/Sites/esports-ui/node_modules/webpack/lib/Compiler.js:397:15)
    at ~/Sites/esports-ui/node_modules/tapable/lib/Tapable.js:103:11
    at Compilation.<anonymous> (~/Sites/esports-ui/node_modules/webpack/lib/Compilation.js:445:10)
    at ~/Sites/esports-ui/node_modules/webpack/lib/Compilation.js:417:12
    at ~/Sites/esports-ui/node_modules/webpack/lib/Compilation.js:332:10
    at ~/Sites/esports-ui/node_modules/webpack/node_modules/async/lib/async.js:52:16

Any insight is much appreciated!

zedd45 commented 7 years ago

Looks like I had a typo in my search, at least on this repo. I found #17, which was filed by my coworker, but doesn't address this specific problem, unless I accidentally wrapped something dynamic in <FormatMessage>. I'll post back if my removing sections of the code troubleshooting bears fruit.

zedd45 commented 7 years ago

Ok, I found it. We had some code my aforementioned coworker had written that took options, and I tried to extract that to a Global Constant for use elsewhere in the codebase (I was trying to directly utilize Globalize to format a number that's being passed to another, 3rd party react component over which I do not have control).

So in the course of refactoring, I tried to change the input to <FormatNumber>, and he had even left a comment about how this cannot be dynamic, which I overlooked when I made this change 🤕

         <FormatNumber options={NUMBER_FORMAT_OPTIONS}>
             {number}
         </FormatNumber>
rxaviers commented 7 years ago

I see you made progress on your search. Please, do you still need any input? Did you find a bug? Thanks

zedd45 commented 7 years ago

I'm not sure where the stack trace originates from, but this error seems to be related to trying to use an object reference for <FormatNumber> versus a "hard coded" object in the props. If I understand correctly, this may be related to globalize-compiler reads the files and generates replacement code?

I have solved the problem in our code base by replacing the reference with an object literal containing the option values, so we can close this, but I would have two questions:

  1. How is the stack trace being handled in this case? I am not sure if there is any way to improve this or not, but the error gave me no indication of what I had done to cause this error (no lines in the stack pointed to my code), and because I stopped one task and switched to another, I lost the context of what happened and had to troubleshoot by removing chunks of code until I found the culprit.
  2. If my hypothesis (derived in part from #17 ) is right then we cannot pass references to props in react-globalize. Is this the case? Will it always be the case? It makes it a little harder to work with. For instance, I'm working on a bread crumb feature now, and I cannot simply take the displayName of the component and drop that into <FormatMessage>, either, because the children special prop gets read & replaced, right?