`worker: true` breaks parsing when minified production settings are used #114

Closed
tony-cocco opened this Issue Nov 19, 2014 · 11 comments

Projects

None yet

3 participants

@tony-cocco

Hello again!

Ran into another issue. If you'll recall my parse command:

Papa.parse(input, {
        header: true,
        dynamicTyping: true,
        worker: true,
        step: function(row) {
          // do stuff...
        },
        complete: function() {
          // stuff
        },
        error: function(err) {
          //stuff
        }
      });

Everything works fine until I go with grunt build and run in production (node w/ express). When this command gets run from prod I get:

Uncaught TypeError: Cannot read property 'defaultView' of undefined.

I tried using the papaparse.min.js to determine if it's grunt's uglify that is busting it but that seems to have no effect as the grunt task still concats and uglifies everything together. (I'm using the default gruntfile that the yeoman angular-fullstack-generator creates.)

After a bunch of tests I found that it works again when I comment out worker: true. Which is simple enough to do. The only thing I could find that might be related is this SO. I know the worker makes the call async, so perhaps some context is being lost somewhere?

I'll be leaving out the worker for the time being, but if you discover a fix that'd be great!

Thanks!

@mholt
Owner
mholt commented Nov 19, 2014

That's bizarre. The word "defaultView" doesn't appear anywhere in Papa Parse... and I'm not familiar with grunt. Do you use grunt build in dev, too? Or at least the minified Papa? And it works there?

@tony-cocco

You're telling me... For development I've been using grunt serve. Which does none of the uglifying or minifying, and is debuggable.

I also see other issues with my codemirror text area, however, the input being passed to the parse is correct and the only difference between working and non-working parsing is worker: true.

I'm going to try and comb through the processed JS to see if I can find anything helpful.

Also, thanks for the quick replies!

@tony-cocco

Okay, here's where I'm leaving it for today. I can see that I get to:

w.postMessage({
                input: _input,
                config: config,
                workerId: w.id
            });

And based on the config earlier, when we receive a message we should hit workerThreadReceivedMessage. Based on my log statements, I never get into that method. I don't know that much about how postMessage works but I'll continue investigating tomorrow.

@mholt
Owner
mholt commented Nov 19, 2014

Oh; you're running this in Node, huh. I see that in your original post now, but I missed it earlier (the cost of fast replies). My guess now is that it's because web workers only work in the browser; I don't know of a way to use them in Node.

@tony-cocco

Node is just my server tech. The parse is being called from my angular
controller, which is in chrome. Sorry for the confusion!
On Nov 19, 2014 4:21 PM, "Matt Holt" notifications@github.com wrote:

Oh; you're running this in Node, huh. I see that in your original post
now, but I missed it earlier (the cost of fast replies). My guess now is
that it's because web workers only work in the browser; I don't know of a
way to use them in Node.


Reply to this email directly or view it on GitHub
#114 (comment).

@tony-cocco

I've pinned it down to this block:

    if (IS_WORKER)
        global.onmessage = workerThreadReceivedMessage;
    else if (Papa.WORKERS_SUPPORTED)
        SCRIPT_PATH = getScriptPath();

In the production build, IS_WORKER is always false. I flipped if (IS_WORKER) to if (true) and it parsed. However, the same console outs are not present as the debug version. The big difference is that in production, there's never another call to papa creating a worker.

Below is the chain of logs I get. Maybe you can figure out what's not being called in the production version.

Dev:

Window__proto__: Window papaparse.js:9 // this is the global
setting up papa; is worker? false
// above was printed at page load. below appears when the parse happens
csvtojson
using worker
posting message.
message posted
DedicatedWorkerGlobalScope {undefined: undefined, Infinity: Infinity, Math: MathConstructor, NaN: NaN, Intl: Object…}
setting up papa; is worker? true
MessageEvent {ports: Array[0], data: Object, source: null, lastEventId: "", origin: ""…}  //worker thread handler
csvtojson
main thread
MessageEvent {ports: Array[0], data: Object, source: null, lastEventId: "", origin: ""…} 

Prod:

Window {top: Window, window: Window, location: Location, external: Object, chrome: Object…} //this is the global object passed in
setting up papa; is worker? false
// above was printed at page load. below appears when the parse happens
csvtojson
using worker
posting message.
message posted  // I think nothing is reading this message. or whatever it is, doesn't have defaultView
Uncaught TypeError: Cannot read property 'defaultView' of undefined 
@tony-cocco

Ok. Pulled papaparse out of the build chain and added it post-build. Everything works fine. I'm going to point the blame at some weird ugilfy/minify error.

@tony-cocco tony-cocco closed this Nov 20, 2014
@mholt mholt removed the under review label Nov 20, 2014
@mholt
Owner
mholt commented Nov 20, 2014

Wow, weird! Well, I'm glad you found a way around it. Thanks for posting the debug stuff here in case it happens to anyone else. Parse on!

@no-more
no-more commented Dec 3, 2015

Hello,

I know it's old and closed, but when I ugglify the code (gulp-ugglify-1.5.1) I have an error :
Uncaught TypeError: Cannot read property 'window' of undefined

I don't have it if I disable the webworker, or when not minified.

Thanks.

@tony-cocco

Don't concat it with other files. I assume the gulp task is doing something similar to the grunt one.

@no-more
no-more commented Dec 3, 2015

Hello,

Thanks.
Isn't there a way to handle this in the code (I mean by adding some kind of injection)?

In my config I currently have only one file for all js libs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment