I love meteor, but from time to time I do something that makes it get stuck either in “Building”, or something else, and the log isn’t very informative about the reason…
I updated from meteor 1.2 to 1.3, and rearranged all my files to the new imports/ file structure. Now meteor will get stuck at processing files with ecmascript (for....
If I meteor remove ecmascript, it doesn’t get stuck, but then my import commands don’t work…
My other JS are in normal javascript, are they incompatible with ES2015?..
I kinda solved it, although what I did was just avoid the problem.
I figured ecmascript compiler was just taking too long to compile my local packages, and so I moved them back to public folder, where they are not compiled to ES6.
However, I’m now having problems with using an npm package, which meteor 1.3 is supposed to work with now…
I found the solution about that. I was put semantic.js file on client folder. After i get “processing files with ecmascript (for…” i delete it and it worked.
I had the same issue today with a new project - just 1 import but I had a huge js file just sitting in my imports folder(not imported) and it kept getting stuck at “processing files with ecmascript (for…”. I even tried “neter reset” but no luck. Even manually removed .local folder didn’t help/
Really bugged me for a few hours didn’t seem to understand what’s going on but when I deleted that files and went “meteor reset” again and it all worked from there.
It seems to me meteor tool just picks up all the files and compiles them no matter if you include it or not.
I ran into this today after I had previously run meteor build into a directory inside my source directory. In my case, I ran meteor build --directory ./test-build. Once I ran rm -rf test-build the build returned to normal.
I solved my issue by process of elimination. I saved a .js file in my client/js/lib folder while working on a feature. At some point later I accidentally saved my meteor application’s home page in the same folder! Guess I was too tired. Found the folder and then saw the html and a subfolder with meteor-generated scripts. Removed them and everything clicked. My exact steps:
create a new meteor project, copy over package.json and .meteor/packages files
run meteor npm install and then run the project with meteor
while the project is running start copying over root app folders one by one, wait for app to recompile before moving on to each folder
my problem surfaced when I copied over the client folder. Meteor said refreshing client and got stuck there.
I removed the client folder, killed the process (run ps command, kill -9 [PID] where PID is the process id with the high CPU time.) and then restarted meteor again
created client folder manually and then started copying client/* items over one by one
that’s when I noticed the app_name.html and app_name folder with a lot of .js files in it!
I removed them and everything works now. Good luck!
Short for my reply: Use nodejs 0.10.4x version. I’m using with nvm (node version manager)
I was facing same problem with differential:vulcanize package.
When i hit the meteor run it was saying ‘processing files with vulcanize blah blah’ and i was stucking.
What i’ve done:
I cleaned up my system.
Reinstalled my linux distro.
And i use nvm (node version manager) for nodejs & npm.
Instead of using latest version of npm, im using v0.10.46 version number.
I guess i did rest of things same like before.
Now:
Process still take some time to run the server, but its ok. Its working now. I mean it takes time around 45sec-1min to run the server on 3000.
I got the same problem in an application combining Meteor and Polymer. Everything is running smoothly, but when adding more web components, the initial build time increases dramatically. After adding a JSON editor it got really bad.
The problem boiled down to sending large js files from the bower_components (which is located in imports/ui as required by mwc:synthesis) through the ecmascript compiler which is nonsense in the given context.
Currently, the only way to exclude files from being processed seems to be renaming them to “es5.js” which is not practicable for external modules loaded via bower dependencies.
I could not find a way to exclude all js files below “bower_components” so I did some investigation and found the following - hacky - solution:
In our Meteor installation - ~/.meteor - we find a subdir packages and there a package called meteor-tool.
This will have subdirectories for different Meteor versions, pick the one used (currently 1.3.4.1)
somewhere down the tree, in my case mt-os.linux.x86_64/tools/isobuild there is a file called compiler-plugin.js
Locate the function runCompilerPlugins() defined there, it should have a block somewhere near its end:
// Now actually run the handlers.
_.each(sourceProcessorsWithSlots, function (data, id) {
var sourceProcessor = data.sourceProcessor;
var resourceSlots = data.resourceSlots;
var jobTitle = ["processing files with ", sourceProcessor.isopack.name, " (for target ", self.arch, ")"].join('');
Profile.time("plugin " + sourceProcessor.isopack.name, function () {
buildmessage.enterJob({
title: jobTitle
}, function () {
var inputFiles = _.map(resourceSlots, function (resourceSlot) {
return new InputFile(resourceSlot);
});
var markedMethod = buildmessage.markBoundary(sourceProcessor.userPlugin.processFilesForTarget.bind(sourceProcessor.userPlugin));
try {
markedMethod(inputFiles);
} catch (e) {
buildmessage.exception(e);
}
});
});
});
Change its inner block to something like this:
Profile.time("plugin " + sourceProcessor.isopack.name, function () {
buildmessage.enterJob({
title: jobTitle
}, function () {
var inputFiles = [];
if ( procName == 'ecmascript' ) {
// hh DEBUG we skip all bower_components from being compiled
for ( i=0; i<resourceSlots.length; i++ ) {
var inf = new InputFile(resourceSlots[i]);
var path = inf.getPathInPackage();
if (/.*bower_components.*/.test(path)) {
console.log('SKIP: ' + path);
} else {
console.log('Compile: ' + path);
inputFiles.push(inf);
}
}
} else {
// hh DEBUG normal handling for other processors
inputFiles = _.map(resourceSlots, function (resourceSlot) {
return new InputFile(resourceSlot);
});
}
var markedMethod = buildmessage.markBoundary(sourceProcessor.userPlugin.processFilesForTarget.bind(sourceProcessor.userPlugin));
try {
markedMethod(inputFiles);
} catch (e) {
buildmessage.exception(e);
}
});
});
I know it’s bad behaviour but it really should be configurable to exclude directories from being processed by ecmascript. The delay produced by large files can actually kill a build.
