2017-09-27 13 views
2

Ich arbeite an einem Knoten Express API, die eine Sicht über Reagieren und CSS-Module (eine CSS-Datei innerhalb jeder Komponente direkt in die Komponente). Die Antwortausgabe wird mit renderToStaticMarkup() serialisiert, die in der JSON-Antwort an den Anforderer zurückgesendet wird. Ich beabsichtige auch, das kompilierte CSS in dieser Antwort zu senden.CSS Loader Fehler mit Webpack V3 nach dem Bearbeiten einer Webpack Watched Datei in einer serverseitigen App

Ich habe einen funktionierenden Build-Prozess über Webpack, der meine Server-App zu einer Datei bündelt. Ich bin gerade dabei, meine CSS (Module) in eine Datei zu bündeln (mit der Absicht, dies später zu lesen).

I webpack mit seiner Uhr Anlage bin mit wie folgt (nicht webpack-dev-Server verwenden, da die api POST erfordert und es gibt keine ‚Seite‘ sowieso aktualisieren):

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

Mein Problem Allerdings funktioniert dies zwar beim ersten Kompilieren, aber sobald ich eine Datei ändere, erhalte ich einen Webpack-Fehler, der besagt, dass ich einen geeigneten Loader für die importierte CSS-Datei benötige.

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 

Ich habe meine Webpack-Konfiguration so weit wie möglich vereinfacht und bekomme immer noch das Problem. Meine vereinfachte Konfiguration (nicht CSS Extrahieren Datei und keine PostCSS) ist wie folgt:

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; 

Also meine Frage ist, warum funktioniert das in Ordnung auf der ersten Kompilierung aber nicht auf eine Neukompilierung nach einer Änderung?

Antwort

0

Fremder als Fiktion! So

Ich erkannte, dass, wenn ich betreibe meine Build ohne den Beobachter ...

cross-env NODE_ENV=development webpack --colors 

und dieser Prozess beendet hatte, wenn ich eine Datei bearbeitet ich immer noch den Fehler gesehen !!! Obwohl angeblich kein Wächter lief. Ich habe dieses Terminal-Fenster allein gelassen, ohne einen laufenden Prozess, habe ein anderes Terminal geöffnet und eine Datei in meinem src-Verzeichnis mit vi bearbeitet (geschlossenes WebStorm, falls ein seltsamer Watcher ausgeführt wurde). Unglaublicherweise tauchte der Fehler im ursprünglichen Terminalfenster wieder auf !!!

Es scheint also, dass mein Problem durch einen Rogue Webpack Watch Prozess verursacht wurde, der nicht richtig abgetötet wurde. Konnte den Prozess nicht finden, um ihn manuell zu beenden, also musste er neu starten. Buchstäblich verlorene Stunden in diesem bizarren Problem. Zumindest funktioniert mein gesamter Build-Prozess wieder.