Next.js: Désactiver HMR

HMR est toujours pris en charge en mode dev. Il n'y a aucun moyen officiel de l'éteindre.
Nous n'avons pas l'intention de le faire à court terme.

Cela ne causerait-il pas une charge sur le serveur, nous avons besoin d'un moyen de désactiver HMR pour l'exécution en production.

C'est parti en production. Assurez-vous que vous utilisez next build et next start ou next build et NODE_ENV=production node server.js en production.

Désactiver HMR peut être utile lorsque vous travaillez sur la mise en page. J'édite styled-components et certains styles css globaux, mais l'aperçu est bientôt cassé. La raison en est que la page obtient un mélange de styles rendus par SSR et de ceux qui viennent d'être générés. Il semble qu'il n'y ait aucun moyen de surmonter cela, sauf en éteignant le HMR.

En plus du fait que HMR n'est toujours compatible qu'avec ES5 (tout le monde n'a plus besoin de transpiler des classes), j'ai régulièrement rencontré des bugs liés à HMR spazzy qui ne se produisent que dans le développement. J'aimerais vraiment avoir un moyen de le désactiver.

Même une solution hacky serait appréciée. Ça tourne au cauchemar.

Je crois que je rencontre un problème connexe. J'essaye actuellement d'utiliser react-waypoint dans une page Next.js. Lorsque j'appelle this.setState depuis un gestionnaire d'événement Waypoint, j'obtiens une erreur Maximum call stack size exceeded . Cela se produit uniquement lors de l'exécution de Next.js en mode dev. Si je npm run build et npm start le problème ne se produit pas.

Peut-être en rapport avec ce problème ?

De toute façon, nous pourrions rouvrir ce problème. L'HMR peut être très ennuyeux dans plusieurs situations. Si ce n'est pas une priorité, pouvez-vous fournir des informations sur l'endroit où trouver ce code (pour le désactiver manuellement) et/ou faire un PR @arunoda

En ce moment, nous rencontrons d'énormes problèmes avec Apollo GraphQL + Next JS (5.0.0). getDataFromTree ne fonctionne tout simplement pas et cela casse beaucoup de choses dans notre configuration :(

@timneutkens , @arunoda , pouvez-vous rouvrir ceci ?

Et au fait https://github.com/zeit/next.js/issues/1938#issuecomment -358195616

ressemble à un problème avec shouldComponentUpdate . Une chose importante à savoir est qu'en mode dev, ces fonctions ne sont pas appelées en raison des limitations de la fonctionnalité de
Je dirais exécuter en mode production localement et ajouter une journalisation à vos fonctions.

Cela semble être une chose importante

Parfois, je voudrais désactiver HMR en mode dev juste pour éviter d'encombrer l'onglet réseau des outils de développement avec du bruit de message inutile.

"on-demand-entries-ping?page=/xxx", etc.

Appuyer sur CMD-R pour recharger la page n'est pas un gros problème, redémarrer le serveur pour obtenir les mises à jour en mode prod est pénible.

comme solution de contournement, vous pouvez empêcher les requêtes hmr avec la fonctionnalité "Blocage des requêtes" des outils de développement Chrome

@vanmik Excellent conseil, merci ! ??

Pour trouver le blocage des demandes dans Chrome (66 au moins), vous devrez peut-être :

ouvrez 'Personnaliser et contrôler DevTools' (trois points verticaux) > More tools > Request Blocking . Cela ouvrira la console de blocage des requêtes où vous pourrez vérifier les sources de requêtes à bloquer, comme indiqué dans la capture d'écran de

Vous voulez mentionner que vous n'êtes pas limité aux outils de développement avec cela. Vous pouvez utiliser un plugin de navigateur pour bloquer les demandes. Dans ce cas, vous n'avez pas besoin de garder les outils de développement ouverts à chaque fois juste pour cela.

Mais j'espère qu'à l'avenir nous obtiendrons quelque chose de simple comme :

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

La GRH craint. Cela apporte plus souvent des difficultés que des avantages (par exemple, lorsque certaines parties du code sont rechargées à chaud alors que d'autres ne le font pas, ce qui provoque un état incohérent).

Alors que l' astuce de http://localhost:3000/_next/on-demand-entries-ping?page=/xxx , seulement maintenant ce sont des erreurs.

Non acceptable pour le débogage :-/

J'aimerais bien avoir

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

Peut-être que quelqu'un pourrait écrire un plugin pour cela ???

@gihrig vous pouvez filtrer ces erreurs avec le menu contextuel de la console (clic droit sur l'erreur):

@arunoda Des progrès à ce sujet ? J'ai un problème avec les proptypes HMR et immutablejs - super frustrant. Voir : https://github.com/facebook/prop-types/issues/221

Ma solution de contournement consistait à activer request blocking , puis à ajouter la demande on-demand-entries-ping à la liste des demandes bloquées. J'espère que cela aidera les autres qui n'aiment pas HMR autant que moi.

Pour désactiver le rechargement de module à chaud (HMR) dans Next.js v7+, ajoutez ceci à votre fichier next.config.js :

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

Cela désactivera la reconstruction en cas de modification, ce qui à son tour empêchera le navigateur de « voir » les modifications et, par conséquent, ne rechargera rien. Cela signifie que Next.js ne sera pas recompilé en cas de modifications . Vous devrez redémarrer le serveur next.js à chaque changement, puis actualiser votre navigateur.

Pour une solution qui force le rechargement d'une page entière à chaque changement, voir ce commentaire ci-dessous .

FWIW fusionnera bientôt : https://github.com/zeit/next.js/pull/4508

Pour une solution qui rechargera toujours la page sur les changements , vous pouvez créer un server.js :

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
});

Je suis sûr à 80% que ça va casser à l'avenir.

C'est un hack horrible, mais la seule façon pour moi de contourner un bogue qui ferait que l'onglet du navigateur consommerait> 100% du processeur, puis se bloquerait dans Chrome à chaque rechargement à chaud.

Espérons qu'au moment où le hack s'arrêtera, il y aura une solution officielle ou les bugs mentionnés dans ce problème seront corrigés 👍

La raison pour laquelle je souhaite désactiver HMR est que le panneau DevTools/Applications/Cookies (Chrome Windows) perd le focus lorsque vous le saisissez, car les mises à jour HMR continuent de se produire en arrière-plan. Je soupçonne que ce serait le cas même si je disais à webpackDevServer d'ignorer tous les fichiers. La connexion websocket serait toujours établie en arrière-plan et je pense que c'est cette connexion qui écrase le panneau des cookies.

Le point étant : une solution idéale doit désactiver complètement HMR. Merci!

Il est regrettable que vous ne puissiez pas simplement ajouter cela à votre next.config.js

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

Cette option demande au module de fonctionner en mode « paresseux », ce qui signifie qu'il ne se recompilera pas lorsque les fichiers changent, mais plutôt à chaque demande. Cela ressemble à quelque chose que beaucoup d'entre nous espèrent sans avoir à aller aussi loin que les solutions de @jesstelford .

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

Lorsque j'essaye ceci sur next 7.0.2 , j'obtiens l'erreur suivante :

J'ai eu l'occasion de travailler avec un projet Create React App aujourd'hui.

Je pense que la racine de ce problème HMR n'est pas tant que l'HMR est maléfique, mais plutôt la façon dont elle est mise en œuvre.

En termes simples, demander au client d'interroger périodiquement le serveur est loin d'être idéal.

D'après une observation rapide, il semble que CRA utilise une connexion socket qui ne communique avec le client que lorsqu'un fichier a changé, puis le client recharge la page. Ce schéma entraîne également une actualisation plus rapide du navigateur car l'opération ne dépend pas du prochain intervalle d'interrogation.

CRA est open source . Ce serait formidable si quelqu'un avec le temps et l'intérêt pouvait se lancer dans la mise à niveau du HMR de Next pour suivre le modèle CRA (et le rendre également facilement désactivé, bien sûr :-)

@gihrig, il y a probablement plusieurs raisons différentes pour lesquelles les gens cherchent à désactiver HMR.

Je crois comprendre que react-hot-loader nécessite certaines hypothèses sur la façon dont votre application est écrite, comment l'état est modélisé et l'absence d'identité d'objet significative. Ces hypothèses sont généralement valables pour une application basée sur redux correctement écrite, mais peuvent ne pas être valables pour des applications conçues à l'aide d'autres approches. Je suis d'accord que le problème n'est pas que l'HMR est maléfique - c'est juste que ce n'est pas un outil générique. Cela crée une certaine dissonance dans le contexte d'un cadre qui est par ailleurs agnostique quant à ces décisions de conception.

Passer du sondage aux Websockets est probablement une bonne idée, mais le sondage n'est pas « la racine du problème », ou plutôt il n'est pas lié à au moins certains des problèmes rencontrés par les gens ici.

Notez que les deux derniers commentaires font des hypothèses erronées :

• Next.js n'utilise pas react-hot-loader, il restitue l'arborescence des composants lorsqu'un changement est émis
• Next.js ne fait pas de sondage pour recevoir des modifications, il fait un sondage pour marquer quelles pages sont encore consultées, sur Canary, cela a été changé en un websocket juste pour que l'utilisateur ne voit pas le sondage se produire dans leurs devtools. Pour développer davantage ce HMR fonctionne à l'aide d'une connexion à la source d'événements, ce qui signifie que le serveur envoie des événements (lors d'un changement de fichier) au navigateur.

@timneutkens C'est bon à entendre, merci. Ce n'était pas une fausse hypothèse, cependant, c'était une information obsolète. RHL était utilisé lorsque nous avons commencé à utiliser Next et c'est la cause des problèmes que nous avons rencontrés qui m'ont amené à commenter à l'origine dans ce fil. Cependant, je n'ai vu aucun problème lié à HMR lors de l'utilisation de Next depuis un certain temps.

En fait, nous sommes maintenant en mesure d'exécuter notre version ES2017 en développement !

Après 2 ans de personnes se plaignant de HMR, il n'y a toujours pas de moyen officiel de le désactiver ?!!

Pourquoi cette connexion GET /_next/on-demand-entries-ping?page=/ sur mon application NON next.js ?

-- auto-résolu: a dû commenter le logger app.use.(morgan(dev)) la chose étrange est que Morgan est installé sur une autre application sans next.js, donc quelque chose se passe avec ce qui est enregistré par Morgan, je veux savoir pourquoi ça arrive. Cela ne se produisait pas avant d'installer next.js sur un projet différent.

Veuillez rouvrir le problème n'est définitivement pas résolu.

+1