An syntax error in a less file crash the meteor process

MickaelFM · August 16, 2019, 10:49am

An syntax error in a less file crash the meteor process.
Had anyone else had this happen ?

=> Started proxy.

/home/mick/.meteor/packages/meteor-tool/.1.8.1.4ie9oe.sh0wq++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/fibers/fibers.js:90
					return fn.apply(this, arguments);
					          ^
[object Object]

Process finished with exit code 1

coagmano · August 17, 2019, 12:40am

This sounds similar to something I ran into with the stylus compiler:

github.com/meteor/meteor

Lazy compilation errors swallowed in certain circumstances

opened 07:37AM - 04 Dec 18 UTC

coagmano

confirmed Project:Isobuild

I ran into a rather cryptic error today on a new project (Meteor 1.8.0.1): ``` … => Started proxy. internal/process/next_tick.js:131 callback(); ^ [object Object] ``` Which unfortunately gives no hints on where the issue was. The only clue was issue #10343, where it was a coffeescript / compiler issue. I'm not using coffeescript, but I am using my stylus plugin `coagmano:stylus` (and others, but later on I discover it was a styl file at fault) So I tried removing `compileOneFileLater` from the plugin, at which point the process no longer errored out, but instead on the client I get `Uncaught Error: Cannot find module './style.styl'`. Because there was a compilation error, it did not end up creating the wrapper for ES module imports. The file in question was trying to `@require` a file that didn't exist. Easily fixed. I wanted to figure out why the error reporting was so bad in this case, so I added `compileOneFileLater` back into the plugin and dug through Meteor to find that the error is thrown here: https://github.com/meteor/meteor/blob/devel/tools/isobuild/compiler-plugin.js#L961 Where the error object is of the shape `{ message, info: { file, line, column, func } }`. Which when thrown is `toString()`ed to `[object Object]` as the message to a new `Error`. It seems the simplest solution to get better error output is to throw the message instead of the whole object, or stringify it a little nicer first. (I tried it out running Meteor from checkout and even just throwing the message was much nicer) Now I tried to create a reproduction for this bug report, but everything seemed to work correctly until I started to replicate the complexity of the original import. [Reproduction here](https://github.com/coagmano/nextTick-error) To understand the level of indirection here, we have a [package with a lazy `mainModule`](https://github.com/coagmano/nextTick-error/blob/master/packages/compile-test/package.js#L18), and a [white-list](https://github.com/coagmano/nextTick-error/blob/master/packages/compile-test/whitelist.js#L1-L3) for dynamic `import()` added with `api.addFiles` Both files point to `indirection.js` which then imports the faulty stylus file. Which gave me this error: <details> ``` => Started proxy. STYLUS ERROR SHOULD GET PASSED ON NOW - /Users/fredstark/.meteor/packages-from-server/tmc11.localX8000/meteor-tool/.1.8.0_1.4y59k5.fbopm++os.osx.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-promise/promise_server.js:218 throw error; ^ undefined => awaited here: at Promise.await (/Users/fredstark/.meteor/packages-from-server/tmc11.localX8000/meteor-tool/.1.8.0_1.4y59k5.fbopm++os.osx.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-promise/promise_server.js:60:12) at JsOutputResource.finalize (/tools/isobuild/compiler-plugin.js:897:7) at JsOutputResource.hasPendingErrors (/tools/isobuild/compiler-plugin.js:924:10) at JsOutputResource.reportPendingErrors (/tools/isobuild/compiler-plugin.js:929:14) at ImportScanner._scanFile (/tools/isobuild/import-scanner.js:849:14) at each (/tools/isobuild/import-scanner.js:907:14) at _.each._.forEach (/Users/fredstark/.meteor/packages-from-server/tmc11.localX8000/meteor-tool/.1.8.0_1.4y59k5.fbopm++os.osx.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:87:22) at ImportScanner._scanFile (/tools/isobuild/import-scanner.js:871:5) at each (/tools/isobuild/import-scanner.js:907:14) at _.each._.forEach (/Users/fredstark/.meteor/packages-from-server/tmc11.localX8000/meteor-tool/.1.8.0_1.4y59k5.fbopm++os.osx.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:87:22) at ImportScanner._scanFile (/tools/isobuild/import-scanner.js:871:5) at outputFiles.forEach.file (/tools/isobuild/import-scanner.js:529:14) at Array.forEach (<anonymous>) at ImportScanner.scanImports (/tools/isobuild/import-scanner.js:527:22) at sourceBatches.forEach.batch (/tools/isobuild/compiler-plugin.js:1301:17) at Array.forEach (<anonymous>) at Function.computeJsOutputFilesMap (/tools/isobuild/compiler-plugin.js:1269:19) at ClientTarget._emitResources (/tools/isobuild/bundler.js:1121:8) at buildmessage.enterJob (/tools/isobuild/bundler.js:847:12) at Object.enterJob (/tools/utils/buildmessage.js:388:12) at ClientTarget.make (/tools/isobuild/bundler.js:835:18) at /tools/isobuild/bundler.js:3143:14 at webArchs.forEach.arch (/tools/isobuild/bundler.js:3294:25) at Array.forEach (<anonymous>) at /tools/isobuild/bundler.js:3248:14 at Object.capture (/tools/utils/buildmessage.js:283:5) at bundle (/tools/isobuild/bundler.js:3124:31) at files.withCache (/tools/isobuild/bundler.js:3069:32) at Object.withCache (/tools/fs/files.js:1712:12) at Object.bundle (/tools/isobuild/bundler.js:3069:16) at Profile.run (/tools/runners/run-app.js:569:24) at Function.run (/tools/tool-env/profile.js:490:12) at bundleApp (/tools/runners/run-app.js:568:34) at AppRunner._runOnce (/tools/runners/run-app.js:610:35) at AppRunner._fiber (/tools/runners/run-app.js:908:28) at /tools/runners/run-app.js:398:12 ``` </details> Which is... not the same error 😓 Again, the error goes away when `importOneFileLater` is removed (instead client displays correct error message after an import) I've checked and the [finalizer](https://github.com/coagmano/meteor-stylus/blob/master/plugin/compile-stylus.js#L60-66) passed to `inputFile.addStylesheet` doesn't throw an error, since that is [caught in `compileOneFile`](https://github.com/coagmano/meteor-stylus/blob/master/plugin/compile-stylus.js#L300-L307) when `getResult` is called (where it calls `inputFile.error` and returns null) I'm pretty sure it's got something to do with how the stylesheet finalizer is wrapped for consumption as a JS module when it has errors (or returns null (or both!)). No idea about the first error, but it would be great to have proper error handling in this edge case.

It seems to happen when the styles imported in javascript, meaning a JS wrapper file needs to be created by the compiler, but if the compilation fails, there’s no file to wrap and the whole thing throws.

Normally you get the compilation error immediately, but if you are using lazy loaded packages and dynamic imports, it loses the error in the extra layers of wrappers and indirection required.