CSS loader error with webpack v3 after editing a webpack watched file in a server-side app

Viewed 82

I am working on a node express api which is building a view via react and CSS modules (one CSS file within each component imported directly into the component). The react output is serialised with renderToStaticMarkup() which will be sent back to the requester in the JSON response. I also intend to send the compiled CSS in this response too.

I have a working build process via webpack which bundles my server app to one file. I am also currently bundling my CSS (modules) into one file (with the intention of reading this in later).

I am using webpack with its watch facility as follows (can't use webpack-dev-server as the api requires POST and there is no 'page' to update anyway):

cross-env NODE_ENV=development webpack -w --colors

My issue however is that whilst this all works fine on first compile, as soon as I change any file, I get a webpack error stating that I need an appropriate loader for the imported CSS file.

ERROR in ./src/app/components/Suggestions/Suggestions.css
Module parse failed: /home/me/myproject/src/app/components/Suggestions/Suggestions.css Unexpected token (1:0)
You may need an appropriate loader to handle this file type.
| .suggestions {
|     background: blue;
|     color: orange;
 @ ./src/app/components/Suggestions/Suggestions.js 11:19-47
 @ ./src/app/components/Suggestions/index.js
 @ ./src/server/middleware/buildSuggestions.js
 @ ./src/server/routes/index.js
 @ ./src/server/server.js
 @ multi babel-polyfill ./src/server/server.js

I have simplified my webpack config as much as possible and still get the issue. My simplified config (not extracting css to file and no PostCSS) is as follows:

webpack.config.babel.js

import path from 'path';
import nodeExternals from 'webpack-node-externals';

import PATHS from './config/paths';

// Host and port settings to spawn the dev server on
const HOST = 'localhost';
const PORT = 3000;
const LOCAL = `http://${HOST}:${PORT}`;
const DEV = process.env.NODE_ENV === 'development';

let serverConfig = {
  entry: [
    "babel-polyfill",
    path.resolve(PATHS.src, 'server/server.js'),
  ],

  output: {
    filename: 'server.js',
    path: PATHS.dist,
    publicPath: '/'
  },

  module: {
    rules: [
      {
        test: /\.jsx?$/,
        include: PATHS.src,
        use: {
          loader: 'babel-loader',
          options: {
            // babelrc at project root only for compiling this webpack
            babelrc: false,
            presets: [
              'env',
              'react'
            ],
            plugins: [
              'transform-object-rest-spread',
              'syntax-dynamic-import',
              'transform-class-properties',
            ]
          }
        }
      },
      {
        test: /\.css$/,
          use: [
            {
              loader : 'css-loader',
              options: {
                modules: true,
                importLoaders: 1,
                localIdentName: '[local]-[hash:base64]',
                sourceMap: DEV
              },
            }
          ]
      }
    ],
  },

  plugins: [
  ],

  target: 'node',
  externals: [nodeExternals()]
};

export default serverConfig;

So my question is, why does this work okay on first compile but not on a recompile after a change?

1 Answers

Stranger than fiction!

So I realised that if I run my build without the watcher...

cross-env NODE_ENV=development webpack --colors

and that process had ended, if I edited a file I still saw the error!!! Even though there was supposedly no watcher running. I left that terminal window alone with no running process, opened another terminal and edited a file within my src directory using vi (closed WebStorm in case it had some odd watcher running). Incredibly, the error popped up again in the original terminal window!!!

So it seems my issue was caused by a rogue webpack watch process that hadn't been killed properly. Couldn't find the process to manually kill it so had to do reboot. Literally hours lost on this bizzare issue. At least my whole build process is working again.

Related