Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Out of memory error on jsx processing #558

Closed
mbektimirov opened this issue Jan 21, 2015 · 9 comments
Closed

Out of memory error on jsx processing #558

mbektimirov opened this issue Jan 21, 2015 · 9 comments
Labels
outdated A closed issue/PR that is archived due to age. Recommended to make a new issue

Comments

@mbektimirov
Copy link

I am using 6to5 with jsx, gulp and browserify. After several file changes 6to5 crashes with error: FATAL ERROR: JS Allocation failed - process out of memory. I've found out that the problem is with my jsx source by simply switching entry point to js file instead jsx. See the console trace and my configuration below. Pay attention on increasing build time after each bundle change.

Tested with the latest 6to5-core

[20:08:04] Running 'bundle'...
[20:08:05] Finished 'bundle' in 73 ms
[BS] File changed: build/app.js
[20:08:10] Running 'bundle'...
[20:08:11] Finished 'bundle' in 88 ms
[BS] File changed: build/app.js
[20:08:13] Running 'bundle'...
[20:08:14] Finished 'bundle' in 367 ms
[BS] File changed: build/app.js
[20:08:18] Running 'bundle'...
[20:08:36] Finished 'bundle' in 17 s
[BS] File changed: build/app.js
[20:08:42] Running 'bundle'...
FATAL ERROR: JS Allocation failed - process out of memory
[1]    23299 abort      gulp

Browserify Gulp task:

var browserify   = require('browserify');
var watchify     = require('watchify');
var bundleLogger = require('../util/bundleLogger');
var gulp         = require('gulp');
var handleErrors = require('../util/handleErrors');
var source       = require('vinyl-source-stream');
var _6to5        = require('./6to5ify');
var externalLibs = require('../external-libs');

gulp.task('browserify', function() {

    var bundler = browserify({
    cache: {}, packageCache: {}, fullPaths: true,
        entries: ['./src/scripts/test_app.jsx'],
        extensions: ['.js', '.jsx'],
        debug: false, 
    paths: ['./src/scripts'],
    fast: true,
    detectGlobals: false
    });


  var bundle = function() {
    bundleLogger.start();

    return bundler
      .external(externalLibs)
      .transform(_6to5)
      .bundle()
      .on('error', handleErrors)
      .pipe(source('app.js'))
      .pipe(gulp.dest('./build/'))
      .on('end', bundleLogger.end);

    if(global.isWatching) {
                bundler = watchify(bundler);
        bundler.on('update', bundle);
    }

    return bundle();
});

test_app.jsx:

var React = require('react');

var Test = React.createClass({

  render: function() {
    return (
      <h1>Test</h1>
    );
  }

});

React.render(<Test />, document.getElementById('root'));
@gaearon
Copy link
Member

gaearon commented Jan 21, 2015

Node version? Can you put up a reproducible example?
Do you have this issue when using 6to5 directly (as opposed to 6to5ify)?

BTW I find it faster to skip node_modules with 6to5, do you do that?

@mbektimirov
Copy link
Author

I put logging to 6to5ify. Generated source code and source maps are duplicated and grow on each transform call even if I reset the data:

// ...
return function (filename) {
   // ...
    var data = "";

    var write = function (buf) {
      data += buf;
      console.log('data', data);
    };

    var end = function () {
      var opts2 = _.clone(opts);
      opts2.filename = filename;

      try {
        var out = to5.transform(data, opts2).code;
      } catch(err) {
        stream.emit("error", err);
        stream.queue(null);
        return;
      }

      stream.queue(out);
      stream.queue(null);
      data = '';
    };

    var stream = through(write, end);
    return stream;
  };

@mbektimirov
Copy link
Author

Disabling source maps and ignoring node_modules gives the same result.

@gaearon
Copy link
Member

gaearon commented Jan 21, 2015

I suppose this is 6to5ify issue then?

@mbektimirov
Copy link
Author

I don't think so. Other transformation libs use the same approach with through without any issues. How can I test it in browserify without 6to5ify?

@gaearon
Copy link
Member

gaearon commented Jan 21, 2015

I put logging to 6to5ify. Generated source code and source maps are duplicated and grow on each transform call even if I reset the data:

Where does duplication occur? I don't quite understand yet.

@mbektimirov
Copy link
Author

@gaearon, you're absolutely right, my browserify task was wrongly configured. I put transform outside the bundle function and the problem has gone:

var bundler = browserify({...});
bundler.transform(_6to5.configure({
  ignore: 'node_modules',
  sourceMap: false
}));

var bundle = function() {
  return bundler
    .external(externalLibs)
    // previously it was here
    //.transform(_6to5)
    .bundle()
    .on('error', handleErrors)
    .pipe(source('app.js'))
    .pipe(gulp.dest('./build/'))
   .on('end', bundleLogger.end);
};

This link helped me to catch the problem: https://github.com/gulpjs/gulp/blob/master/docs/recipes/fast-browserify-builds-with-watchify.md
Thanks for your attention 👍

@gaearon
Copy link
Member

gaearon commented Jan 21, 2015

Thank you for sharing the solution!

mbektimirov added a commit to vectormap/vector-online-ios that referenced this issue Jan 21, 2015
@JoshSGman
Copy link

This was giving me a headache too, thanks for this!

JacopKane pushed a commit to JacopKane/babel that referenced this issue Jan 11, 2018
JacopKane pushed a commit to JacopKane/babel that referenced this issue Jan 13, 2018
@lock lock bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Jul 27, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Jul 27, 2018
kaicataldo pushed a commit that referenced this issue Nov 14, 2019
… called (fixes #558)(#559)

* Prevent parseForESLint() behavior from changing after parse() is called

(fixes babel/babel-eslint#558, fixes eslint/eslint#9767)

* Avoid using the enhanced referencer after monkeypatching

* Chore: add test for #558

* Pass correct scope analyzer options

* fix escope patch and improve tests

* remove process.exit(1)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated A closed issue/PR that is archived due to age. Recommended to make a new issue
Projects
None yet
Development

No branches or pull requests

4 participants