Babel-errors are not forwarded to stderr

[IMalyugin]

Babel-watch closes if there are some internal errors without logging the error. The most common case is babel-configuration error, if there is such, it is lost during app.on('message', handler), since erorros throws inside message handlers aren't forwarded to stderr.

[IMalyugin]

At the moment, we've got this:

Error: Command failed: babel-watch %path% --extensions .js,.jsx,.ts,.tsx
    at checkExecSyncError (node:child_process:828:11)
    at Object.execSync (node:child_process:902:15)
    at Object.<anonymous> (%path%:7:4)
    at Module._compile (node:internal/modules/cjs/loader:1103:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1157:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12)
    at node:internal/main/run_main_module:17:47 {
  status: 1,
  signal: null,
  output: [ null, null, null ],
  pid: 27014,
  stdout: null,
  stderr: null
}

With fix in PR, We'll get this:

Error: Caching has already been configured with .never or .forever()
    at CacheConfigurator.using (../node_modules/@babel/core/lib/config/caching.js:190:13)
    at Object.caller (../node_modules/@babel/core/lib/config/helpers/config-api.js:31:30)
    at module.exports (./babel.config.js:28:75)
    at startHiding - secret - don't use this - v1 (../node_modules/@babel/core/lib/errors/rewrite-stack-trace.js:55:12)
    at readConfigJS (../node_modules/@babel/core/lib/config/files/configuration.js:93:66)
    at readConfigJS.next (<anonymous>)
    at Function.<anonymous> (../node_modules/@babel/core/lib/gensync-utils/async.js:21:3)
    at Generator.next (<anonymous>)
node:child_process:905
    throw err;
    ^

Error: Command failed: babel-watch %path% --extensions .js,.jsx,.ts,.tsx
    at checkExecSyncError (node:child_process:828:11)
    at Object.execSync (node:child_process:902:15)
    at Object.<anonymous> (%path%:7:4)
    at Module._compile (node:internal/modules/cjs/loader:1103:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1157:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12)
    at node:internal/main/run_main_module:17:47 {
  status: 1,
  signal: null,
  output: [ null, null, null ],
  pid: 27014,
  stdout: null,
  stderr: null
}

[STRML]

Ok, it looks like this function releases Zalgo:

https://github.com/kmagiera/babel-watch/blob/6a22386bda5f2cb3119343fa218b16be66688307/babel-watch.js#L490-L507

specifically at L491.

Wrapping that in a try/catch then calling back with the err should fix the issue, so long as the error is not ignored inside handleFileLoad.

[IMalyugin]

Don't really need to wrap with try/catch, if we plan to propagate error. It propagates well, but is ignored at the top level, even above handleFileLoad - inside app.on('message', handler)

[STRML]

I don't follow.

[IMalyugin]

Me neither :) Did you mean we should use callback to pass the error to handleFileLoad instead of catching the error after it propagates?