Error: rails-erb-loader failed with code: 1

[Swat123]

Running the following:
ruby -e $stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift) /Users/swathishah/shopify-app/bin/spring rails --trace assets:precompile

But I randomly get following error:

ERROR in ./app/javascript/components/layout_tab.js.erb
Module build failed: Error: rails-erb-loader failed with code: 1
    at ChildProcess.<anonymous> (/Users/swathishah/shopify-app/node_modules/rails-erb-loader/index.js:108:16)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at maybeClose (internal/child_process.js:886:16)
    at Socket.<anonymous> (internal/child_process.js:342:11)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at Pipe._handle.close [as _onclose] (net.js:501:12)
 @ ./app/javascript/components/tabs.js 12:0-44
 @ ./app/javascript/packs/notifications_react.jsx

Package.json has following:

{
  "name": "shopify-app",
  "private": true,
  "dependencies": {
    "@rails/webpacker": "^3.2.1",
....
   "rails-erb-loader": "^5.4.1",
...
    "yarn": "^1.3.2"
  },
  "devDependencies": {
    "webpack-dev-server": "^2.11.1"
}

[rhys-vdw]

Hi @Swat123. I don't know why this is happening exactly, but I can explain the general context of this error message and maybe we can improve the reporting or find out what's going wrong.

When rails-erb-loader loads a single file:

• It runs a Ruby script in a new process. The script waits for data to be piped into it.
• rails-erb-loader streams the input file to the process via stdin
• The script transforms the source and prints it out.
• rails-erb-loader reads all the stdout from the script (this will be the output)
• When the process closes, if it ended without error (ie. returned code 0) then the loader succeeds and the transpiled source is given to webpack.

Typically with Rails you'd use bin/rails runner to execute the transformer script, and you can see that this is the approach that webpacker uses.

In short: bin/rails runner is exiting with an error code.

For @Swat123

I would have expected error output to be piped through to the main process, so you should see error logs on screen if they're printed. Is there any logging before you see that error? If no, is it possible that the wrapper task you're running is somehow suppressing stderr from webpack? I'm aware of webpacker's existence, but I haven't used it myself.

But I randomly get following error[...]

By "randomly" you mean that it only happens sometimes right? If this is the case it might be being caused by spring. You could try running the process with DISABLE_SPRING=1 and see if that stops it. It might make your build slower, but it would help explain the problem.

You can either add it to your loader config:

options: { runner: 'DISABLE_SPRING=1 bin/rails runner' }

Or you should be able to set it with your rails command:

DISABLE_SPRING=1 ruby -e $stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift) /Users/swathishah/shopify-app/bin/spring rails --trace assets:precompile

(uh... actually looking at the above you might need to remove the explicit call to spring)

Good luck!

For rails-erb-loader

Even if this issue turns out to be out of our control, I'd like to know how we can improve the error reporting from the loader. At very least we should update the error message to something like:

rails-erb-loader: "bin/rails runner" closed with exit code 1

It's also unclear to me why the 'close' callback is being called instead of the 'error' callback.

Additionally I'd like to double check and add test coverage to ensure that we are indeed piping stderr through to the console successfully.

[Swat123]

Thank you so much. You are right it is spring. Disabling spring gets me rid of the error. Any way I can debug and pull in more trace info so that it can help others ?

[rhys-vdw]

Hey @Swat123, thanks for getting back to me. Glad I could help.

Yes, absolutely. If you're willing to put in some work there are a few actionables here...

1. Improve the error message to include the actual executable that returned the error code (see my previous comment)
2. Confirm that spring is actually not outputting any error information on stderr. My understanding is that we're reporting all information to the user at the moment, and you're seeing nothing in this case. There's a chance that spring is actually printing a meaningful error and we're accidentally suppressing it. If this is the case we might need to change the way we handle stderr.
3. Add a troubleshooting section to the README that suggests trying to disable spring for random failures/hangs. This should still suggest opening/commenting in issues so we can try to nail them down.
4. Do some research to see if there are any relevant issues about spring failing silently with error code 1. Perhaps there is a known workaround or at least something we can link to in the README.

Any effort on any of these would be greatly appreciated, thanks. :)

[rhys-vdw]

I wonder if we can learn something from the spring server command...

[dreyks]

options: { runner: 'DISABLE_SPRING=1 bin/rails runner' }

I tried this for other ENV var that i needed and this does not work. parseRunner splits by spaces so the ENV var becomes a file that spawn tries to call

[rhys-vdw]

@dreyks oh dear!

[kofronpi]

I'm also affected by this with undecipherable errors. I will investigate and report back.

[rhys-vdw]

Thanks @kofronpi. It's hard for me to investigate because I am not experiencing this issue at the moment.

[akaspick]

I'm going mad trying to deploy to a production env with rails-erb-loader...

ERROR in ./app/javascript/packs/components/repeat_dialog.vue.erb
Module build failed: Error: rails-erb-loader failed with code: null
    at ChildProcess.<anonymous> (/home/deploy/app/releases/353/node_modules/rails-erb-loader/index.js:108:16)
    at ChildProcess.emit (events.js:182:13)
    at maybeClose (internal/child_process.js:947:16)
    at Socket.stream.socket.on (internal/child_process.js:368:11)
    at Socket.emit (events.js:182:13)
    at Pipe._handle.close [as _onclose] (net.js:598:12)
Child extract-text-webpack-plugin node_modules/extract-text-webpack-plugin/dist node_modules/css-loader/index.js??ref--1-2!node_modules/postcss-loader/lib/index.js??ref--1-3!node_modules/bootstrap-daterangepicker/daterangepicker.css:
       2 modules
Child extract-text-webpack-plugin node_modules/extract-text-webpack-plugin/dist node_modules/css-loader/index.js??ref--1-2!node_modules/postcss-loader/lib/index.js??ref--1-3!node_modules/fullcalendar/dist/fullcalendar.min.css:
       2 modules
Child extract-text-webpack-plugin node_modules/extract-text-webpack-plugin/dist node_modules/css-loader/index.js??ref--1-2!node_modules/postcss-loader/lib/index.js??ref--1-3!node_modules/fullcalendar-scheduler/dist/scheduler.min.css:
       2 modules
Child extract-text-webpack-plugin node_modules/extract-text-webpack-plugin/dist node_modules/css-loader/index.js??ref--1-2!node_modules/postcss-loader/lib/index.js??ref--1-3!node_modules/select2/dist/css/select2.min.css:
       2 modules
Child extract-text-webpack-plugin node_modules/extract-text-webpack-plugin/dist node_modules/css-loader/index.js?minimize!node_modules/vue-loader/lib/style-compiler/index.js?{"optionsId":"0","vue":true,"scoped":false,"sourceMap":false}!node_modules/sass-loader/lib/loader.js!node_modules/vue-loader/lib/selector.js?type=styles&index=0!app/javascript/packs/components/target_table.vue:
       2 modules
Child extract-text-webpack-plugin node_modules/extract-text-webpack-plugin/dist node_modules/css-loader/index.js?minimize!node_modules/vue-loader/lib/style-compiler/index.js?{"optionsId":"0","vue":true,"id":"data-v-3dc4e503","scoped":true,"sourceMap":false}!node_modules/sass-loader/lib/loader.js!node_modules/vue-loader/lib/selector.js?type=styles&index=0!app/javascript/packs/components/target_input.vue:
       2 modules
Child extract-text-webpack-plugin node_modules/extract-text-webpack-plugin/dist node_modules/css-loader/index.js?minimize!node_modules/vue-loader/lib/style-compiler/index.js?{"optionsId":"0","vue":true,"id":"data-v-25afaeb2","scoped":true,"sourceMap":false}!node_modules/sass-loader/lib/loader.js!node_modules/vue-loader/lib/selector.js?type=styles&index=1!app/javascript/packs/components/target_table.vue:
       2 modules

My package.json:

{
  "dependencies": {
    "@rails/webpacker": "3.5",
    "bootstrap-daterangepicker": "^2.1.25",
    "caniuse-lite": "^1.0.30000697",
    "coffeescript": "1.12.7",
    "css-loader": "^0.28.11",
    "expose-loader": "^0.7.3",
    "file-loader": "^0.11.2",
    "foundation-datepicker": "^1.5.6",
    "fullcalendar": "^3.4.0",
    "fullcalendar-scheduler": "^1.6.2",
    "jquery": "^3.2.1",
    "moment": "^2.18.1",
    "rails-erb-loader": "^5.4.1",
    "select2": "^4.0.3",
    "slm": "^1.0.0",
    "vue": "^2.5.16",
    "vue-loader": "14.2.2",
    "vue-template-compiler": "^2.5.16",
    "webpack": "^3.0.0"
  },
  "devDependencies": {
    "webpack-dev-server": "2.11.2"
  }
}

Any ideas? There is nothing to tell me what actually went wrong. This is occurring on my production Ubuntu 14.04 server.

[akaspick]

Follow up to my last message... now compilation works with no changes to the server. Stress on the randomly in this issues title. I'll keep testing to see if there's any pattern to this... server load, etc.

[rhys-vdw]

@akaspick I was on holiday.

It seems our failure is here.

  child.on('close', function (code) {
    if (code === 0) {
      // ...
    } else if (child.killed) {
      // ...
    } else {
      callback(new Error('rails-erb-loader failed with code: ' + code))
    }
  })

Explanation here.

If the process exited, code is the final exit code of the process, otherwise null. If the process terminated due to receipt of a signal, signal is the string name of the signal, otherwise null. One of the two will always be non-null.

So should look like this:

  child.on('close', function (code, signal) { // <-- Add signal param here
    if (code === 0) {
      // ...
    } else if (child.killed) { // <-- I'm _assuming_ this is the same as `signal === 'SIGKILL'`
      // ...
    } else if (signal !== null) {  // <-- Add this handler
      callback(new Error('rails-erb-loader terminated by signal: ' + signal))
    } else {
      callback(new Error('rails-erb-loader failed with code: ' + code))
    }
  })

@akaspick you should get more information if we implement these changes. I'm a little behind having just returned from a break. Are you up to making this change?

[akaspick]

@rhys-vdw I'd love to make the change, but I don't have a reliable way to reproduce the issue. I had non-stop issues one evening last week and then the following day and after I haven't seen the issue since. If this comes up again, I'll take another look. Thanks for the reply.

[rhys-vdw]

@akaspick no problem, see #65.