sintaxi / harp

Static Web Server/Generator/Bundler
http://harpjs.com
5k stars 343 forks source link

Range error when compiling #538

Closed jaukia closed 8 years ago

jaukia commented 8 years ago

When calling "harp compile . ../build" I keep getting range error, even when I remove all files from the directory that is compiled! It looks like the compile works and the static files are generated correctly.

Harp server works ok.

Running Os X 10.11.2, Node.js version v4.3.1, NPM version 2.14.12, Harp version 0.20.1.

Error starts like this:

Transformers.verbatim is deprecated, to continue using the :verbatim jade filter after jade@2.0.0, you will need to install jstransformer-verbatim.
/usr/local/lib/node_modules/harp/lib/index.js:0

RangeError: Maximum call stack size exceeded
  at String.replace (native)
  at Object.exports.shouldIgnore (/usr/local/lib/node_modules/harp/node_modules/terraform/lib/helpers/raw.js:423:23)
  at copyFile (/usr/local/lib/node_modules/harp/lib/index.js:232:27)
  at replenish (/usr/local/lib/node_modules/harp/node_modules/async/lib/async.js:176:21)
  at /usr/local/lib/node_modules/harp/node_modules/async/lib/async.js:188:33
  at copyFile (/usr/local/lib/node_modules/harp/lib/index.js:238:7)
  at replenish (/usr/local/lib/node_modules/harp/node_modules/async/lib/async.js:176:21)
  at /usr/local/lib/node_modules/harp/node_modules/async/lib/async.js:188:33
  at copyFile (/usr/local/lib/node_modules/harp/lib/index.js:238:7)
  at replenish (/usr/local/lib/node_modules/harp/node_modules/async/lib/async.js:176:21)
  at /usr/local/lib/node_modules/harp/node_modules/async/lib/async.js:188:33
  at copyFile (/usr/local/lib/node_modules/harp/lib/index.js:238:7)
  at replenish (/usr/local/lib/node_modules/harp/node_modules/async/lib/async.js:176:21)
  at /usr/local/lib/node_modules/harp/node_modules/async/lib/async.js:188:33
  at copyFile (/usr/local/lib/node_modules/harp/lib/index.js:238:7)
  at replenish (/usr/local/lib/node_modules/harp/node_modules/async/lib/async.js:176:21)
lunelson commented 8 years ago

I'm getting this too, as of this morning

bauhouse commented 8 years ago

I'm running into the same issue on harp compile: RangeError: Maximum call stack size exceeded

Except that for me, compile is modifying some of the binary assets (images and videos) when there are no changes to these files.

Running OS X 10.11.3, Node version 5.1.0, NPM version 3.5.3, Harp version 0.20.1

naomiblack commented 8 years ago

I'm seeing the same issue. OS X 10.11.3, Node 4.1.1, NPM 2.14.7, Harp 0.20.1.

I can temporarily fix by deleting and recreating my github client, but that seems unnecessarily extreme...

sintaxi commented 8 years ago

Thanks for reporting this. Does anyone happen to have a reliable way to reproduce this issue?

jvandemo commented 8 years ago

@sintaxi — Cloning https://github.com/angular/angular.io and running:

$ npm install
$ npm run harp -- compile . ./www

consistently reproduces the problem.

I have troubleshooted a bit and replacing async.eachLimit with async.each on https://github.com/sintaxi/harp/blob/master/lib/index.js#L252 and https://github.com/sintaxi/harp/blob/master/lib/index.js#L256 seems to fix the problem.

Not sure if eachLimit is required or recommended over each. If not I can provide a quick PR to fix the problem.

Feel free to let me know how to proceed. Thanks!

jvandemo commented 8 years ago

Quick update: the fix above seems to work well for the Angular team as well: https://github.com/angular/angular.io/issues/982

bauhouse commented 8 years ago

Thank you! Just to confirm, this fix in Harp version 0.20.3 has resolved the RangeError issue for me as well.

sintaxi commented 8 years ago

Great. Thanks for reporting.

On Wednesday, April 6, 2016, Stephen Bau notifications@github.com wrote:

Thank you! Just to confirm, this fix in Harp version 0.20.3 has resolved the RangeError issue for me as well.

— You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub https://github.com/sintaxi/harp/issues/538#issuecomment-206447471

naomiblack commented 8 years ago

I've just had this crop up again on Angular, using 0.20.3...

We do have a large number of small files in our site, due to examples for our developer docs.

RangeError: Maximum call stack size exceeded
  at String.replace (native)
  at Object.exports.shouldIgnore (/Users/naomib/.nvm/versions/node/v4.1.1/lib/node_modules/harp/node_modules/terraform/lib/helpers/raw.js:423:23)
  at copyFile (/Users/naomib/.nvm/versions/node/v4.1.1/lib/node_modules/harp/lib/index.js:232:27)
  at replenish (/Users/naomib/.nvm/versions/node/v4.1.1/lib/node_modules/harp/node_modules/async/lib/async.js:176:21)
  at /Users/naomib/.nvm/versions/node/v4.1.1/lib/node_modules/harp/node_modules/async/lib/async.js:188:33
jvandemo commented 8 years ago

@naomiblack — When I:

it seems to output the www directory correctly. I can also run gulp serve-and-sync without issues.

Which exact commands are you running? (I will try to reproduce locally)

Thanks!

matthewmayer commented 8 years ago

Note, I'm pretty sure that this is due to the fact that copyFile sometimes calls its callback synchronously. See https://github.com/caolan/async#synchronous-iteration-functions for a solution using setImmediate.

jvandemo commented 8 years ago

@naomiblack — I have created a gist with a change to harp to handle the file copies and compilations asynchronously, as @matthewmayer suggested.

You can find the gist here: https://gist.github.com/jvandemo/caeaef6cc3073cd19760d6b841642524

I haven't been able to reproduce the problem here locally, so can you try and replace node_modules/harp/lib/index.js in your local angular.io repository with the contents of the gist and see if that resolves your problem?

If it does, I can create a PR to the harp repository. Thanks!

sintaxi commented 8 years ago

I'm really bogged down right now. How do you feel about having commit rights an you run with it?

jvandemo commented 8 years ago

@sintaxi — Whatever you feel most comfortable with Brock. It would be an honor to help you out with this.

jvandemo commented 8 years ago

Quick update: received feedback from @naomiblack that she wasn't able to reproduce the issue consistently and that there was another issue that was causing too many files to be created.

So all is ok for now until further notice.

sintaxi commented 8 years ago

Thanks for the update. Happy to hear this isnt a problem.