webpack --watch breaking site after modifying a file

[juan-bastidas]

Do you want to request a feature or report a bug? Report a bug

What is the current behavior?

Working with webpack --watch option breaks the page after modifying a file.

If the current behavior is a bug, please provide the steps to reproduce.

I have an application built with react, one of the components is using a node_module and importing a css file like:

import 'module/styles/styles.css';

I start the build using --watch option and everything is built OK and the site loads fine.
The after modifying any file I get the following error:

Uncaught (in promise) TypeError: webpack_require(...) is not a function

This error points to the CSS file:

exports = module.exports = require("../../css-loader/lib/css-base.js")();

The error is on the line above, which will call:

// style-loader: Adds some css to the DOM by adding a <style> tag

// load the styles
var content = require("!!../../css-loader/index.js!./styles.css");
if(typeof content === 'string') content = [[module.id, content, '']];

Debugging this, the first time webpack is built module ID here is 914 but after modifying the file it is 1, something is very weird when webpack rebuilds after the change.

I have a loader for CSS as follows:

        {
            test: /\.css$/,
            loader: 'style-loader!css-loader'
        },

What is the expected behavior?

After modifying a file the site should reload fine instead of showing the error and breaking the page.

If this is a feature request, what is motivation or use case for changing the behavior?

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.

Node: 6.9.4
Webpack: 3.3.0 but tested on latest too
WIndows 8.1 enterprise

[jussch]

I'm seeing something like this bug as well. It started happening when I updated redux-saga from 0.11.1 to 0.15.6. Never happened before, but now I can't get rid of it, regardless of downgrading redux-saga or not.

Specifcally, the first build is okay, no problems. Upon rebuilding it an error occurs:

import createSagaMiddleware from 'redux-saga'

const middleware = createSagaMiddleware();
// #=> Uncaught TypeError: (0 , _reduxSaga2.default) is not a function

And when inspecting createSagaMiddleware, it reveals an object that looks just like the object I'd get if I did console.log(require('redux-saga'))--like its losing the es6 module status.

[geminiyellow]

me too. at first i think that is a redux-form bug, but i found it cause by 3.3

redux-form/redux-form#3269

my module looks like that:

module.exports = xxxxx;

and i import it

import fuck from 'xxxxx';
console.log(fuck);

->

{default: func}

but update to 3.3

{default: {default: func}}

[sokra]

Thanks for your report. It would be great if you reduce your issue to a small reproducible example. Best put this example into a github repository together with instructions how to get to the problem.

[jonthenerd]

Seeing what I believe is the same issue. In my project, I have a common file for all node_modules and a file specific to my code. From what I can tell, when using the watch option, after 1->3 edits of my code, the generated .js file will have a moduleId (looking at the comments above each array item in the generated js file) assigned (possibly more) that conflict with the moduleIds in the common file (one with module ID 111 became module 11 and is strangely placed at the very top of the new file with the below mentioned commenting format change). This breaks page loading, obviously. Additionally, the format of the comments above a particular webpack module change from:

/* 1234 */
/***/

to:

/***/ 1234:
/***/

So far, the issue has only occurred on a Windows machine (but not a Mac with the same project files and node_modules). Commenting out the commonChunksPlugin (and having all files compile into just 1 js file) works fine. Reverting to 2.7.0 didn't seem to fix my build.

[juan-bastidas]

In my case:

exports = module.exports = webpack_require(/*! ../../css-loader/lib/css-base.js */ 914)();

After the first edit when webpack is listening for files changes is changed into:

exports = module.exports = webpack_require(/*! ../../css-loader/lib/css-base.js */ 1)();

[jonthenerd]

Comparing the stats generated by webpack (just dumping them to a .json file and comparing with winmerge) doesn't reveal anything in my case. Interestingly, even though I see that one of my modules went from id 111 -> 11 in the generated .js file, in the stats.json it is correct @ 111.

[jonthenerd]

Comparing the files built after watch between the working Mac and the non-working Windows machine, the format of the generated .js file is significantly different. The file built on first execution (before any changes) is identical between the machines.

Working post-watch build (Mac) and Original (Windows & Mac)

/* 1234 */
/***/

Non-working post-watch build (Windows)

/***/ 1234:
/***/

Not being familiar with the source code of webpack, where should I start to look for how this is being done differently? At this point, I'm bypassing the webpack watch and doing manual builds... I'd love to figure out what's going on here and get it addressed.

[juan-bastidas]

@sokra I've been trying to create a demo where the issue can be reproduced, just a small project, but I've trying to do a lot in order to identify what is causing the problem, I'm using same webpack configuration as in the project with the issue, and no luck.

What is happening is that a module ID is modified after the first change with watch mode from:

exports = module.exports = webpack_require(/*! ../../css-loader/lib/css-base.js */ 914)();

To:

exports = module.exports = webpack_require(/*! ../../css-loader/lib/css-base.js */ 1)();

So css-base.js is requested with wrong module ID, this lines are extracted from the module created for the CSS file. Also found that in this case for the list of loaded module 914 does not exist.

Do you have any advice on how to hunt this down? Or at least to get more useful information to provide here?

Thanks

[twothe]

I am currently fighting a similar issue, where Webpack seems to confuse the module numbers after a change to the code has caused a recompile.

In this screenshot from Chrome debugging you can see that at the point where Webpack tries to require React, it instead returns the String "fonts/icons.eot", which is not of type object and therefore causes undefined issues later on. The resulting error message varies without any pattern with the only constant that at some point the code calls a React component which is however in fact a String and therefore has no object properties.

The code is working perfectly fine at the first run, it always breaks after a recompile happens, no matter what is changed in the code or where.

This is currently a huge issue for us, as we always have to do a full (1 minute) recompile every time the code is changed.

[twothe]

This issue might be related to Babel. While experimenting we set modules to false in babelrc:

"presets": [
  ["es2015", { "modules": false,"loose" : true }],
  "stage-0",
  "react"
],

Now the issue no longer appears. I am not sure however if that actually solved the issue or just suppressed it for now.

[juan-bastidas]

The problem seems to be with extract-text-webpack-plugin, I downgraded it from 3.0.0 to 2.1.2 and issue went away, more information on webpack-contrib/extract-text-webpack-plugin#579

[TheLarkInn]

Has this been confirmed on latest webpack@3.4.1? If not could you please test and make sure if it is still a problem or not. If not, feel free to close the issue.

[juan-bastidas]

Yes I tested on webpack@3.3.0 and also on webpack@3.4.1, issue on both versions.

[TheLarkInn]

Thank you kindly for confirming. Just to confirm is this specifically a ExtractTextWebpackPlugin issue?

[juan-bastidas]

Well in my case downgrading it just fixed the problem, but as you can see other people in this thread is complaining about similar issues and different modules, and all of them related to watch mode.

[jonthenerd]

Happy to report that upgrading to webpack@3.4.1 resolved my particular issue. Haven't been able to reproduce it since the upgrade. FWIW, my build isn't using the ExtractTextWebpackPlugin. In case others stumble across this, the modules I have affecting webpack are:

• Awesome-Typescript-Loader
• CheckerPlugin (from awesome-typescript-loader)
• CommonChunksPlugin

Glad you at least found a workaround @juan-bastidas . I'm still curious what was causing this (for the both of us).

[gewisser]

Same problem. Demonstrated in the video:
https://youtu.be/CdLJGuyVNxQ

Webpack version: 3.5.1
I use vue.js

My config is below:

const path = require('path');
const webpack = require('webpack');
const ExtractTextPlugin = require("extract-text-webpack-plugin");
const HtmlWebpackPlugin = require('html-webpack-plugin');

function resolve (dir) {
    return path.join(__dirname, '..', dir)
}


module.exports = {
    entry: './src/main.js',
    output: {
        path: path.resolve(__dirname, './dist'),
        publicPath: '/dist/',
        filename: 'build.js'
    },
    module: {
        rules: [
            {
                test: /\.vue$/,
                loader: 'vue-loader',
                options: {
                    loaders: {
                        css: ExtractTextPlugin.extract({
                            use: 'css-loader',
                            fallback: 'vue-style-loader' // <- это внутренняя часть vue-loader, поэтому нет необходимости его устанавливать через NPM
                        })
                    }
                    // other vue-loader options go here
                }
            },
            {
                test: /\.js$/,
                loader: 'babel-loader',
                exclude: /node_modules/,
                include: [resolve('src'), resolve('test')]
            },
            {
                test: /\.pug$/,
                loader: "pug-loader",
                options: {
                    pretty: true
                }
            },
            {
                test: /\.(png|jpg|gif|svg)$/,
                loader: 'file-loader',
                options: {
                    name: '[name].[ext]?[hash]'
                }
            },
            {
                test: /\.(woff2?|eot|ttf|otf)(\?.*)?$/,
                loader: 'null-loader'
            },
            {
                test: /\.css$/,
                use: ExtractTextPlugin.extract({
                    fallback: 'style-loader',
                    use: 'css-loader'
                })
            }
        ]
    },
    resolve: {
        alias: {
            'vue$': 'vue/dist/vue.esm.js'
        }
    },
    devServer: {
        historyApiFallback: true,
        noInfo: true
    },
    performance: {
        hints: false
    },

    devtool: '#eval-source-map',

    plugins: [
        new ExtractTextPlugin("style.css"),
        new HtmlWebpackPlugin({
            filename: 'index.html',
            chunks: ['index'],
            template: './src/index.pug'
        }),
        new webpack.ProvidePlugin({
            $: 'jquery',
            jQuery: 'jquery',
            'window.$': 'jquery',
            'window.jQuery': 'jquery',
        })
    ]

}

if (process.env.NODE_ENV === 'production') {
    module.exports.devtool = '#source-map'
    // http://vue-loader.vuejs.org/en/workflow/production.html
    module.exports.plugins = (module.exports.plugins || []).concat([
        new webpack.DefinePlugin({
            'process.env': {
                NODE_ENV: '"production"'
            }
        }),
        new webpack.optimize.UglifyJsPlugin({
            sourceMap: true,
            compress: {
                warnings: false
            }
        }),
        new webpack.LoaderOptionsPlugin({
            minimize: true
        })
    ])
}

[DannyFeliz]

Same error here!

[blackn1ght]

Yeah, same error here. One minute it was working fine, suddenly it wasn't.

Issue happens on webpack@3.10.0 and 3.4.1. Not using the ExtractTextPlugin.

From what I can tell, at least in my case, when watch runs, it's only building the app bundle and not the vendor bundle. I think this is causing the module ID's to become out of sync and thus it's trying to import the incorrect module.

Update
It started working correctly again after I restarted my machine.

Update 2
It randomly broke again without me touching webpack's, or any other config. Restarting my machine fixed it.

[mt-deva]

Same error here webpack@3.10.0, extract-text@3.0.2
Downgrading extract-text & webpack doesn't resolve it

Update
This was related to babel for me, I changed useBuiltIns: 'usage' to useBuiltIns: 'entry' which resolved the Issue

[calinbuzatu]

Webpack breaks the code after modifying a file in watch mode. For me, the issue was solved downgrading extract-text-webpack-plugin from ^3.0.2 to 2.1.2

[webpack-bot]

This issue had no activity for at least half a year.

It's subject to automatic issue closing if there is no activity in the next 15 days.

[webpack-bot]

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.