Causing error overload

[davidtheclark]

I develop with watchify running. The addition of 6to5ify, though, is breaking that process, causing the following error:

FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory

Any ideas why this would be? I'm fairly certain that 6to5ify is the culprit, because the memory error never occurred before I added this, and goes away if I switch back to reactify.

[sebmck]

The only thing that could be causing this would be a memory leak and index.js is pretty small. Can't seem to see anything that would point to one though.

[davidtheclark]

Another piece of the puzzle: I see that the bytes being written are increasing dramatically in the run before it crashes:

734451 bytes written (2.65 seconds)
751951 bytes written (0.46 seconds)
903365 bytes written (0.46 seconds)
5610405 bytes written (1.59 seconds)
FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory

[sebmck]

@davidtheclark What version of browserify are you using? It's most likely related to #15

[davidtheclark]

I'm sorry ... I think it had to do with the ordering of code in my gulpfile. I'm still not exactly sure what was going on, but if I attached the transforms at different places in the code, I can eliminate this error. Probably not related to 6to5 at all I suppose.

[mattstyles]

I'm getting something very similar, but it seems to be 6to5ify, as it doesnt happen if I comment out the transform. gist of my script build task, although to confuse things it does also use gulp a little later, I'll investigate simplifying everything.

my main.js file referenced is simply

console.log( 'a' );

I ran a few tests, just changing the the string and resaving. Without the transform it wrote 5436 every time (for about 10 or so runs), with the transform the number of bytes written just grew and grew (although didnt break).

I'll have a play but I've just been mucking around and with more stuff in main I could get it to break consistently after 3 rebuilds. Using destructing, spread, templates, let and one class extension. I'll have a play later to try and narrow it down to something that can actually be fixed, something screwy is going on somewhere, although it does sound like a browserify error as I've had something very similar using reactify instead of 6to5ify.

browserify 8.0.3 8.1.1
6to5ify 3.1.2

update: did some tests, identical behaviour to #15, but not fixed in 8.1.1. Happens even with debug:false, although at a tiny rate.

fixed: but only by using 7.0.1.

[sebmck]

@mattstyles I'm doubtful it'd be a 6to5ify issue. The source is only 53 lines long so it's pretty easy to desk check.

[mattstyles]

Yeah I had a hump through, reactify actually broke far earlier than 6to5ify (whereas stuff like envify and brfs are fine, although those reasons are outline in #15), but, in any case, it looks like a browserify issue.

browserify ^7.0.1 fixes it, 8.x breaks it again :(