requirejs / r.js

Runs RequireJS in Node and Rhino, and used to run the RequireJS optimizer
Other
2.57k stars 674 forks source link

Error with plugins when running concurrently #859

Open OliverJAsh opened 8 years ago

OliverJAsh commented 8 years ago

I am running r.js builds in concurrently (using grunt-concurrent). The AMD modules I am building use a plugin: https://github.com/mikach/requirejs-babel

I get this error:

{ [Error: Error: Loader plugin did not call the load callback in the build:
transpile:
  transpile!es6/bootstraps/crosswords_unnormalized2: Error: Load timeout for modules: transpile!es6/bootstraps/crosswords_unnormalized2
http://requirejs.org/docs/errors.html#timeout
Module loading did not complete for:
    at Function.build.checkForErrors (/Users/OliverJAsh/Development/frontend/node_modules/requirejs/bin/r.js:30026:19)
]
  originalError:
   [Error: Loader plugin did not call the load callback in the build:
   transpile:
     transpile!es6/bootstraps/crosswords_unnormalized2: Error: Load timeout for modules: transpile!es6/bootstraps/crosswords_unnormalized2
   http://requirejs.org/docs/errors.html#timeout
   Module loading did not complete for: ] }

This error only occurs when I run my r.js builds concurrently. If I run them separately, they build fine.

Is this a known issue? If necessary I can create an isolated test case.

jrburke commented 8 years ago

I am not sure how the grunt-concurrent works, but right now the r.js optimizer only uses one loader context, called 'build' to do the tracing. I could see if two builds are triggered at once there could be overlap where they use the same context.

It could also be a globals issue with the requirejs-babel plugin. Looking briefly at: https://github.com/mikach/requirejs-babel/blob/master/es6.js

the var fetchText, _buildMap = {}; variables are outside the define() function, so they could be shared between the two instances of the plugin. First thought is to see about moving those inside the define()'s function to see if that helps, if using that es6.js version of the file directly.

Maybe using the .min.js version of that plugin after it has gone through babelfication would be enough of a test, could not make out the globals in that form.

If that does not, then we might need to look more at a test case, and looking at just creating separate loader contexts for each build run. Using the named one was an artifact of how the build process began, and it was all synchronous, but makes less sense to do now.

But I would definitely want to do the case without those globals in that plugin.