Next.js: HMR deaktivieren

HMR wird im Dev-Modus immer unterstützt. Es gibt keine offizielle Möglichkeit, es auszuschalten.
Wir haben keine Pläne, dies kurzfristig zu tun.

Würde dies nicht zu einer Belastung des Servers führen, benötigen wir eine Möglichkeit, HMR für die Ausführung in der Produktion auszuschalten.

In der Produktion ist es ausgeschaltet. Stellen Sie sicher, dass Sie next build und next start oder next build und NODE_ENV=production node server.js in der Produktion ausführen.

Das Deaktivieren von HMR kann bei der Arbeit am Layout nützlich sein. Ich bearbeite styled-components und einige globale CSS-Stile, aber die Vorschau geht ziemlich bald kaputt. Der Grund dafür ist, dass die Seite eine Mischung aus SSR-gerenderten Stilen und den gerade generierten Stilen erhält. Es scheint keine Möglichkeit zu geben, dies zu überwinden, außer indem HMR ausgeschaltet wird.

Abgesehen davon , dass HMR transpilieren ), bin ich regelmäßig auf Spazzy-Bugs im Zusammenhang mit HMR gestoßen, die nur in der Entwicklung auftreten. Ich würde wirklich gerne eine Möglichkeit haben, es zu deaktivieren.

Sogar eine Hacky-Lösung wäre dankbar. Es wird zu einem Albtraum.

Ich glaube, ich stoße auf ein verwandtes Problem. Derzeit wird versucht, den Wegpunkt in einer Next.js-Seite zu verwenden. Beim Aufrufen von this.setState aus einem Wegpunkt-Ereignishandler erhalte ich einen Maximum call stack size exceeded Fehler. Dies tritt nur auf, wenn Next.js im Entwicklungsmodus ausgeführt wird. Wenn ich npm run build und npm start das Problem nicht auf.

Vielleicht im Zusammenhang mit diesem Problem ?

Jedenfalls könnten wir dieses Problem erneut öffnen. HMR kann in mehreren Situationen sehr ärgerlich sein. Wenn dies keine Priorität hat, können Sie einige Informationen darüber geben, wo Sie diesen Code finden (um ihn manuell zu deaktivieren) und / oder eine PR @arunoda machen

Im Moment haben wir große Probleme mit Apollo GraphQL + Next JS (5.0.0). getDataFromTree funktioniert einfach nicht und das macht viele Dinge in unserem Setup kaputt :(

@timneutkens , @arunoda , kannst du das wieder öffnen?

Und übrigens https://github.com/zeit/next.js/issues/1938#issuecomment -358195616

sieht aus wie ein Problem mit shouldComponentUpdate . Wichtig zu wissen ist, dass diese Funktionen im Dev-Modus
Ich würde sagen, lokal im Produktionsmodus ausführen und Ihren Funktionen etwas Protokollierung hinzufügen.

Das scheint eine große Sache zu sein

Manchmal möchte ich HMR im Entwicklungsmodus deaktivieren, nur um die Netzwerkregisterkarte der Entwicklungstools nicht mit unnötigem Nachrichtenrauschen zu überladen.

"on-demand-Einträge-ping?page=/xxx", etc

Das Drücken von CMD-R zum Neuladen der Seite ist kein großes Problem, ein Neustart des Servers, um Updates im Prod-Modus zu erhalten, ist mühsam.

Als Workaround können Sie HMR-Anfragen mit der Funktion "Anforderungsblockierung" in den Chrome-Entwicklertools verhindern

@vanmik Super Tipp, danke! ✨

Um die Anforderungsblockierung in Chrome (mindestens 66) zu finden, müssen Sie möglicherweise:

Öffnen Sie 'DevTools anpassen und steuern' (drei vertikale Punkte) > More tools > Request Blocking . Dadurch wird die Konsole zum Blockieren von Anfragen geöffnet, in der Sie die zu blockierenden Anfragequellen überprüfen können, wie im

Ich möchte erwähnen, dass Sie damit nicht auf Entwicklungstools beschränkt sind. Sie können ein Browser-Plugin verwenden, um Anfragen zu blockieren. In diesem Fall müssen Sie die Entwicklungstools nicht jedes Mal nur dafür geöffnet lassen.

Aber ich hoffe, dass wir in Zukunft etwas Einfaches bekommen würden:

// next.config.js
module.exports = {
  hmr: false
}

HRM ist scheiße. Es bringt häufiger Schwierigkeiten als Vorteile (zB wenn einige Teile des Codes Hot-reloaded werden, während andere dies nicht tun, was zu einem inkonsistenten Zustand führt).

Während der Tipp von @vanmik den eigentlichen HMR-Vorgang stoppt, ist meine Entwicklerkonsole immer noch mit http://localhost:3000/_next/on-demand-entries-ping?page=/xxx Einträgen überladen, nur jetzt handelt es sich um Fehler.

Nicht akzeptabel zum Debuggen :-/

Natürlich gerne

// next.config.js
module.exports = {
  hmr: false
}

Vielleicht könnte jemand dafür ein Plugin schreiben???

@gihrig Sie können diese Fehler mit dem Kontextmenü der Konsole filtern (Rechtsklick auf den Fehler):

@arunoda Gibt es diesbezüglich Fortschritte? Ich habe ein Problem mit HMR und immutablejs Proptypes - super frustrierend. Siehe: https://github.com/facebook/prop-types/issues/221

Meine Problemumgehung dafür bestand darin, request blocking zu aktivieren und dann die on-demand-entries-ping Anfrage zur Liste der blockierten Anfragen hinzuzufügen. Ich hoffe, es hilft anderen, die HMR nicht so sehr mögen wie ich.

Um das Hot Module Reloading (HMR) in Next.js v7+ zu deaktivieren, fügen Sie dies zu Ihrer next.config.js Datei hinzu:

module.exports = {
  webpackDevMiddleware: (config) => {
    config.watchOptions = config.watchOptions || {};
    config.watchOptions.ignored = [
      // Don't watch _any_ files for changes
      /.*/,
    ];
    return config;
  },
};

Dadurch wird das Neuaufbauen bei Änderung deaktiviert, was wiederum dazu führt, dass der Browser keine Änderungen "sieht" und daher nichts neu lädt. Das bedeutet, dass Next.js bei Änderungen nicht neu kompiliert wird . Sie müssen den next.js-Server bei jeder Änderung neu starten und dann Ihren Browser aktualisieren.

Eine Lösung, die das Neuladen der gesamten Seite bei jeder Änderung erzwingt, finden Sie in diesem Kommentar unten .

FWIW wird demnächst zusammengeführt: https://github.com/zeit/next.js/pull/4508

Für eine Lösung, bei der die Seite bei Änderungen immer neu geladen wird , können Sie ein server.js erstellen :

const next = require('next')

const dev = process.env.NODE_ENV !== 'production'
const app = next({ dev })
const handle = app.getRequestHandler()

app.prepare().then(() => {

  // ℹ️ Below is the magic which forces a page reload on every change
  // ℹ️ From https://github.com/zeit/next.js/issues/1109#issuecomment-446841487

  // The publish function tells the client when there's a change that should be hot reloaded
  const publish = app.hotReloader.webpackHotMiddleware.publish.bind(
    app.hotReloader.webpackHotMiddleware,
  );

  // Intercept publish events so we can send something custom
  app.hotReloader.webpackHotMiddleware.publish = (event, ...rest) => {
    let forwardedEvent = event;

    // upgrade from a "change" to a "reload" event to trick the browser into reloading
    if (event.action === 'change') {
      forwardedEvent = {
        action: 'reload',
        // Only `/_document` pages will trigger a full browser refresh, so we force it here.
        data: ['/_document'],
      };
    }

    // Forward the (original or upgraded) event on to the browser
    publish(forwardedEvent, ...rest);
  };
  // ℹ️ End force page reload on change

  // ... Whatever custom server setup you have. See: https://github.com/zeit/next.js/#custom-server-and-routing
});

Ich bin mir zu 80 % sicher, dass das in Zukunft kaputt gehen wird.

Es ist ein schrecklicher Hack, aber die einzige Möglichkeit, einen Fehler zu umgehen, der dazu führte, dass der Browser-Tab >100% CPU verbraucht und dann bei jedem Hot-Reload in Chrome abstürzt.

Hoffentlich gibt es bis zum Abbruch des Hacks eine offizielle Lösung oder die in dieser Ausgabe erwähnten Fehler werden behoben 👍

Der Grund, warum ich HMR deaktivieren möchte, ist, dass das Bedienfeld DevTools/Applications/Cookies (Chrome Windows) während der Eingabe den Fokus verliert, da die HMR-Updates weiterhin im Hintergrund stattfinden. Ich vermute, dass dies auch dann der Fall wäre, wenn ich webpackDevServer anwies, alle Dateien zu ignorieren. Die Websocket-Verbindung würde immer noch im Hintergrund hergestellt und ich glaube, dass diese Verbindung das Cookie-Panel zerstört.

Der Punkt ist: Eine ideale Lösung muss HMR vollständig deaktivieren. Vielen Dank!

Es ist bedauerlich, dass Sie dies nicht einfach zu Ihrem next.config.js hinzufügen können

module.exports = {
  webpackDevMiddleware: config => {
    config.lazy = true;
    return config;
  },
};

Diese Option weist das Modul an, im "faulen" Modus zu arbeiten, was bedeutet, dass es nicht neu kompiliert wird, wenn sich Dateien ändern, sondern bei jeder Anforderung. Klingt nach etwas, auf das viele von uns hoffen, ohne bis zu den Lösungen von @jesstelford gehen zu müssen.

Quelle : https://github.com/webpack/webpack-dev-middleware#lazy

Wenn ich dies auf next 7.0.2 versuche, erhalte ich die folgende Fehlermeldung:

Hatte heute die Gelegenheit, an einem Create React App-Projekt zu arbeiten.

Ich denke, die Wurzel dieses HMR-Problems liegt nicht darin, dass HMR böse ist, sondern in der Art und Weise, wie es implementiert wird.

Einfach ausgedrückt, ist es nicht ideal, wenn der Client den Server regelmäßig abfragt.

Aus einer flüchtigen Beobachtung ergibt sich, dass CRA eine Socket-Verbindung verwendet, die nur dann mit dem Client kommuniziert, wenn sich eine Datei geändert hat, dann lädt der Client die Seite neu. Dieses Schema führt auch zu einer schnelleren Browseraktualisierung, da der Vorgang nicht vom nächsten Abfrageintervall abhängt.

CRA ist Open Source . Es wäre großartig, wenn jemand mit der Zeit und dem Interesse daran interessiert wäre, Nexts HMR zu aktualisieren, um dem CRA-Modell zu folgen (und es natürlich auch leicht deaktivieren zu können :-)

@gihrig Es gibt wahrscheinlich ein paar verschiedene Gründe, warum Leute HMR deaktivieren möchten.

Nach meinem Verständnis erfordert React-Hot-Loader bestimmte Annahmen darüber, wie Ihre Anwendung geschrieben ist, wie der Zustand modelliert wird und das Fehlen einer signifikanten Objektidentität. Diese Annahmen gelten normalerweise für eine korrekt geschriebene redux-basierte App, aber möglicherweise nicht für Apps, die mit anderen Ansätzen entworfen wurden. Ich stimme zu, dass das Problem nicht darin besteht, dass HMR böse ist – es ist nur kein allgemeines Werkzeug. Dies führt zu einer gewissen Dissonanz im Kontext eines Frameworks, das diese Designentscheidungen ansonsten agnostisch behandelt.

Der Wechsel von Polling zu Websockets ist wahrscheinlich eine gute Idee, aber Polling ist nicht „die Wurzel des Problems“, oder vielmehr hat es nichts mit einigen Problemen zu tun, auf die die Leute hier gestoßen sind.

Beachten Sie, dass die beiden letzten 2 Kommentare falsche Annahmen machen:

• Next.js verwendet kein React-Hot-Loader, es rendert den Komponentenbaum neu, wenn eine Änderung ausgegeben wird
• Next.js führt keine Abfragen durch, um Änderungen zu erhalten. Es führt keine Abfragen durch, um zu markieren, welche Seiten noch angezeigt werden. Auf Canary wurde dies in einen Websocket geändert, damit der Benutzer nicht sieht, dass die Abfrage in seinen Devtools stattfindet. Um dies weiter auszubauen, arbeitet HMR mit einer Ereignisquellenverbindung, d. h. der Server sendet Ereignisse (bei Dateiänderung) an den Browser

@timneutkens Das ist

Tatsächlich sind wir jetzt in der Lage, unseren ES2017-Build in dev auszuführen!

Nach 2 Jahren, in denen sich Leute über HMR beschwert haben, gibt es immer noch keine offizielle Möglichkeit, es zu deaktivieren?!!

Warum ist diese Protokollierung GET /_next/on-demand-entries-ping?page=/ in meiner NON next.js-App?

-- selbstaufgelöst: musste den Logger app.use.(morgan(dev)) auskommentieren. Das Merkwürdige ist, dass Morgan auf einer anderen App ohne next.js installiert ist, also passiert etwas damit, dass dies von protokolliert wird Morgan, ich möchte wissen, warum das passiert. Dies geschah nicht, bevor next.js in einem anderen Projekt installiert wurde.

Bitte öffnen Sie das Problem ist definitiv nicht gelöst.

+1