Build freezes at building for web.browser when there are large number of js files in the imports directory in meteor 1.3

[aruntk]

I've created a repo to demonstrate the issue https://github.com/aruntk/js-load-test
As stated in the title while building meteor gets frozen when I put a large number of js files inside imports directory even if I'm not importing them from the client/server. No error is shown in terminal.
I suspect this is because the ecmascript package going through all js files inside imports irrespective of whether I'm importing them or not.
I think this should change to - go through the files which the user is importing.
Another possible solution(although I prefer the first one) maybe implementing a babelrc file and add files in the ignore field.

[aruntk]

@tmeasday I'm stuck at this issue. Could you please help?

[chip]

Not sure if I could help here, but I was curious to know the best approach for debugging this issue.

Here's what I did, with some help from the Meteor Tool README:

1. Cloned meteor: cd ~/code && hub clone meteor/meteor
2. Cloned js-load-test: hub clone aruntk/js-load-test
3. From both tmux panes I was using, I ran export TOOL_NODE_FLAGS=--debug-brk
4. Run inspector.js: cd ~/code/meteor/dev_bundle/lib/node_modules/node-inspector/bin; ./inspector.js
5. Launched browser: http://127.0.0.1:8080/debug?port=5858
6. Ran the js-load-test against the cloned meteor repo: cd ~/code/js-load-test; ../meteor/meteor

I see the app run until the point of Building the application, but nothing after that.

From the browser (step 5) I don't see a way to open any files to set a breakpoint, so I think I'm missing a step or possibly doing this all wrong.

Maybe someone has suggestions on how I can debug this better? Thanks.

[tmeasday]

Hi @chip,

Thanks for taking a look at this.

When I do this, I see the following:

On immediately loading node inspector:

Not all the tool sources, but a couple of them. I put a break point in project-context.js:

After hitting "continue", I now see the list of files populate on the LHS, and the tool stops at that line:

I can now set breakpoints wherever.

I'm not sure why it does that weird thing but that might help.

[chip]

@tmeasday - Thanks for following up. The problem for me is that the sources aren't listed.

Would you please describe the steps that you followed to get them load? Thanks.

[tmeasday]

@chip I'm really not sure what's different. I took the first screenshot above immediately on loading the node-inspector in the browser.

[chip]

Ok, I'm not sure what happened, but I reloaded the browser and was able to open files. I set a number of breakpoints, eventually getting to tools/isobuild/bundler.js, but I haven't yet narrowed it down completely yet. It hangs at Building for web.browser.

[chip]

Actually, I just noticed it says Error 0ding for web.browser, which looks strange. I'll keep looking.

[chip]

With Pause on all exceptions set within Chrome Dev Tools, I'm seeing SyntaxError: Unexpected end of input inside module.js several times as I step through:

Additionally, I'm seeing Syntax error: Unexpected token many times within babylon/index.js:

The last file that I currently see running is babel-traverse/lib/path/context.js, yet I'm not sure exactly where to pinpoint. It doesn't help that I keep losing my breakpoints, so that might be all that I can do unless anyone has further suggestions.

[danlg]

got this issue as well using 1.3.4. sometimes it hangs sometimes the build takes ages, so it's difficult to say if it is systematic.

NODE_ENV=production meteor run ios-device --production --settings settings.json --mobile-server=https://example.com -p 5000

Build tools chain are expected to work. I have an app now which takes 15-20 min to build...when it works. I experienced much more complex system and the build was not so long, complicated and convoluted. This compares poorly with build time of strongly type languages such as C++ which rely on very agressive optimization compiler e.g gcc. I seriously consider leaving Meteor as it kills the productivity and makes me wonder if this is a reliable framework I can rely on.

[aruntk]

@tmeasday Any updates on this issue?

[tmeasday]

@benjamn any thoughts on how the ecmascript cache could have gotten corrupted?

[abernix]

Is anyone still experiencing this problem? If this was the case, it's likely a failed download which has been improved by various updates to the downloader. I'll close this if there are no objections.