Skip to content
This repository has been archived by the owner on Sep 28, 2020. It is now read-only.

errors cause webpack to not build #23

Closed
jongbeau opened this issue Mar 25, 2015 · 22 comments
Closed

errors cause webpack to not build #23

jongbeau opened this issue Mar 25, 2015 · 22 comments

Comments

@jongbeau
Copy link

I have failOnError and failOnWarning set to false, but when the eslint loader detects errors/warnings, my bundle.js never gets created. My loaders look like this:

{ test: /.jsx$/, exclude: /node_modules|bower_components/, loaders: ["react-hot", "jsx-loader", "babel-loader", "eslint-loader"]}

@MoOx
Copy link
Contributor

MoOx commented Mar 25, 2015 via email

@MoOx
Copy link
Contributor

MoOx commented Mar 25, 2015 via email

@jongbeau
Copy link
Author

'use strict'

var webpack = require('webpack')
var path = require('path')

//put environment specific settings in here, to be used in the client
var config = require('./app-config.js')

var definePlugin = new webpack.DefinePlugin({
  CONFIG: JSON.stringify(config)
})

var base_webpack_config = {
  debug: true,
  entry: [
    "./app/js/main.js",
  ],
  output: {
    path: "./public/build/",
    filename: "bundle.js",
        publicPath: "/build/"
  },
  module: {
    loaders: [
      { test: /\.js$/, exclude: /node_modules|bower_components/, loaders: ["babel-loader", "eslint-loader"]},

      { test: /\.woff(2)?(\?v=[0-9]\.[0-9]\.[0-9])?$/, loader: "url-loader?limit=10000&minetype=application/font-woff" },
      { test: /\.(ttf|eot|svg)(\?v=[0-9]\.[0-9]\.[0-9])?$/, loader: "file-loader" },
      { test: /\.scss$/, loader: "style!css!sass?outputStyle=expanded&" +
        "includePaths[]=" + (path.resolve(__dirname, "./node_modules"))
      },
      { test: /\.css$/, loader: "style!css"},
      {
        test: /\.(jpe?g|png|gif|svg)$/i,
        loaders: [
          'file?hash=sha512&digest=hex&name=[hash].[ext]',
          'image?bypassOnDebug&optimizationLevel=7&interlaced=false'
        ]
      },
    ]
  },
  plugins: [
    new webpack.NoErrorsPlugin(),
    definePlugin,
  ],
  eslint: {
    //reporter: require("eslint-friendly-formatter"),
    quiet: true,
    failOnError: false,
    failOnWarning: false,
    emitError: false,
    emitWarning: false
  }
}

var dev_config = function() {
  console.log("using dev webpack.config")
  base_webpack_config.entry.unshift(
    'webpack-dev-server/client?http://localhost:8080',
    'webpack/hot/only-dev-server'
  )
  base_webpack_config.module.loaders.push(
    { test: /\.jsx$/, exclude: /node_modules|bower_components/, loaders: ["react-hot", "jsx-loader", "babel-loader", "eslint-loader"]}
  )
  return base_webpack_config
}

var staging_config = function() {
  console.log("using staging webpack.config")
  base_webpack_config.module.loaders.push(
    { test: /\.jsx$/, exclude: /node_modules|bower_components/, loaders: ["jsx-loader", "babel-loader", "eslint-loader"]}
  )
  return base_webpack_config
}


module.exports = process.env.NODE_ENV === 'staging' ? staging_config() : dev_config()

@jongbeau
Copy link
Author

Any suggestions? Would really love to use as part of our build process.

@MoOx
Copy link
Contributor

MoOx commented Mar 26, 2015

  • emitError & emitWarning are just here to trigger reporter to print the messages via webpack.
    If you set both emit* to false, you will get default behavior. If you want nothing to be emitted, just don't use eslint-loader.
  • failOn* & emit* are not the same.
  • *failOn are off by default to avoid webpack to break the build for "just some linting issues". So you should not have any error/warning that break the build by default.

Even with errors/warnings emitted, webpack should be able to build (even if you see some errors reporter, it's just "visual" errors_).

According to the purpose of the loader, you should use it with default settings (or maybe just change the formatter (reporter).

Sorry you must have something else breaking your build.
I repeat don't be fooled by the output.

Here is an example of build that is actually creating the expected file:

screen shot 2015-03-26 at 14 28 42

@MoOx
Copy link
Contributor

MoOx commented Mar 26, 2015

Just to be sure, the source of this loader is simple enough for you to take a quick look in ./node_modules/eslint-loader/index.js & try to comment this lines https://github.com/MoOx/eslint-loader/blob/master/index.js#L52-L58

@jongbeau
Copy link
Author

Yes, that's how I understand it as well. As soon as I remove eslint-loader from the loaders, everything builds fine.

@MoOx
Copy link
Contributor

MoOx commented Mar 26, 2015

Can you take a quick look in the file I mention & tell me which one break the build ? Is it the emitter() call ?

@MoOx
Copy link
Contributor

MoOx commented Mar 26, 2015

I see that your are using new webpack.NoErrorsPlugin(). Can you try disabling it ?
You can also try to force warning which should not break the build. Just use {emitWarnings: true} to force all eslint messages to be reported as webpack warnings.

@jongbeau
Copy link
Author

I tracked down the issue.
If I comment out this line it works:

emitter(messages)

So it looks like webpack will fail the build if webpack.emitError has any messages.

I believe this line is supposed to overwrite that setting:

else if (webpack.options.eslint.emitWarning) {
  emitter = webpack.emitWarning
}

But by default webpack.options.eslint.options.emitError and webpack.options.eslint.options.emitWarning are not set. So emitError is the active emitter.

I was able to fix the problem by explicitly setting emitWarning = true in the config.

@jongbeau
Copy link
Author

And you were right, it looks like the culprit is the NoErrorsPlugin, which I think many people will be using. I think the best bet is to set options.emitWarning = true by default.

@MoOx
Copy link
Contributor

MoOx commented Mar 26, 2015

Yes, I will change default options if more people complains. Thanks for your investigation with me.

@MoOx MoOx closed this as completed Mar 26, 2015
@levithomason
Copy link

FWIW I wanted to allow builds to be created during development, even with linting warnings/errors. It took a while to understand the settings required. Especially confusing was that using the NoErrorsPlugin was causing the build to not be created on linting errors. This seems backwards and I'm still no sure why this is the case.

Removing the plugin and setting emitWarning: true works but forces all errors to reported as warnings. This ruins the styling in browser making errors look like warnings.

It would be nice if warnings/errors could be reported in tact, styled accordingly in the console and the build could also still complete.

Though, it is working. Thanks for the contribution to open source.

@MoOx
Copy link
Contributor

MoOx commented Sep 15, 2015

@levithomason what you are asking is a webpack change. This loader uses webpack emitWarning/emitError methods and cannot control in browser output.
Feel free to open an issue on webpack and link it here.

@levithomason
Copy link

Thanks for the clarification. Will let it be. I got this working for our flow by treating Webpack's lint as a convenience only and implenting a separate gulp lint task for tests and the build.

@BryceHayden
Copy link

I know that we are having a similar problem, and are considering moving to only have the linter run through .git-hooks and removing eslint from our webpack build.

@MoOx
Copy link
Contributor

MoOx commented Jun 29, 2016

Like I said, you can use emitWarning: true option to force all eslint error/warning being reported as warnings https://github.com/MoOx/eslint-loader#emitwarning-default-false
Alternatively, you can use eslint to define your rules as warning, not errors, and force warnings to be reported as error via emitError for production builds.

But keep in mind that both error and warning are blocking hot update when NoErrorsPlugin is used https://github.com/MoOx/eslint-loader#gotchas

@MoOx
Copy link
Contributor

MoOx commented Jun 29, 2016

Also, if you don't want this loader to report anything that might prevent the build from being made, just don't use this loader 🙃!
The best thing to do anyway is to use configure eslint in your text editor/IDE and use eslint CLI in your build step on CI. Don't use this loader if it cause you more trouble than it can solves.

@BryceHayden
Copy link

Sounds good, thank @MoOx

@nelsieborja
Copy link

nelsieborja commented Nov 9, 2017

In case you want Webpack [latest] to detect errors/warnings but should still be able to build (but with warnings), do the ff:

    rules: [
      {
        ...
        loader: "eslint-loader",
        options: {
          emitWarning: true,
          configFile: "./.eslintrc.json"
        }
      },
      ...
    ]

Reference here

@awthwathje
Copy link

awthwathje commented Mar 21, 2018

With Webpack 4.2 just

{
  enforce: 'pre',
  loader: 'eslint-loader',
  ...
  options: {
    emitWarning: true
  }
}

works for me.

@maciej-gurban
Copy link

maciej-gurban commented Apr 24, 2018

I'm not sure if this is webpack related, or if I'm doing something wrong, but failOnError and emitError are false by default according to the docs. And yet, when parsing code that contains an error, webpack will fail with Failed to compile.

Here's my configuration:

{
  test: /\.js$/,
  exclude: /node_modules/,
  use: [
    { loader: 'eslint-loader', options: { emitError: false, failonError: false } },
  ],
  enforce: 'pre',
},

Am I missing or misunderstanding something basic about what an error is, or in what circumstances will this fail? Happening for [email protected] and [email protected]. Also, if it's relevant, I'm using [email protected] and [email protected] - so not using webpack-dev-server but having my own node-based dev server.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants