Next.js: Desactivar HMR

HMR siempre se admite en el modo de desarrollo. No hay una forma oficial de apagarlo.
No tenemos planes de hacerlo a corto plazo.

¿No causaría esto una carga en el servidor? Necesitamos una forma de apagar HMR para que se ejecute en producción.

Está en producción. Asegúrese de ejecutar next build y next start o next build y NODE_ENV=production node server.js en producción.

Desactivar HMR puede resultar útil cuando se trabaja en el diseño. Estoy editando styled-components y algunos estilos CSS globales, pero la vista previa se rompe muy pronto. La razón es que la página obtiene una combinación de estilos renderizados por SSR y los recién generados. Parece que no hay forma de superar esto excepto apagando el HMR.

Además de que HMR sigue siendo compatible solo con ES5 (ya no todos necesitan transpilar clases), me he encontrado regularmente con errores relacionados con HMR que ocurren solo en el desarrollo. Realmente me encantaría tener una forma de desactivarlo.

Incluso se agradecería una solución hacky. Se está convirtiendo en una pesadilla.

Creo que me encuentro con un problema relacionado. Actualmente estoy tratando de usar react-waypoint en una página de Next.js. Cuando llamo a this.setState desde un controlador de eventos de Waypoint, recibo un error de Maximum call stack size exceeded . Esto solo ocurre cuando se ejecuta Next.js en modo dev. Si npm run build y npm start el problema no ocurre.

¿Quizás relacionado con este tema ?

De cualquier forma podríamos reabrir este problema. HMR puede ser muy molesto en múltiples situaciones. Si esto no es una prioridad, ¿puede proporcionar alguna información de dónde encontrar ese código (para deshabilitarlo manualmente) y / o hacer un PR @arunoda

En este momento estamos experimentando grandes problemas con Apollo GraphQL + Next JS (5.0.0). getDataFromTree simplemente no funciona y esto rompe muchas cosas en nuestra configuración :(

@timneutkens , @arunoda , ¿puedes reabrir esto?

Y por cierto https://github.com/zeit/next.js/issues/1938#issuecomment -358195616

parece un problema con shouldComponentUpdate . Lo importante que debe saber es que en el modo de desarrollo, estas funciones no se llaman debido a las limitaciones de la funcionalidad de
Yo diría que se ejecuta en modo de producción localmente y agrega algunos registros a sus funciones.

Esto parece algo importante

A veces me gustaría deshabilitar HMR en el modo de desarrollo solo para evitar saturar la pestaña de red de herramientas de desarrollo con ruido de mensajes innecesario.

"entradas-a-demanda-ping? page = / xxx", etc.

Presionar CMD-R para volver a cargar la página no es un gran problema, reiniciar el servidor para obtener actualizaciones en modo prod es una molestia.

Como solución alternativa, puede evitar las solicitudes de hmr con la función "Bloqueo de solicitudes" de las herramientas de desarrollo de Chrome.

@vanmik ¡ Gran consejo, gracias! ✨

Para encontrar el bloqueo de solicitudes en Chrome (al menos 66), es posible que deba:

abra 'Personalizar y controlar DevTools' (tres puntos verticales)> More tools > Request Blocking . Esto abrirá la consola de bloqueo de solicitudes donde puede verificar las fuentes de solicitud para bloquear, como se muestra en la captura de pantalla de

Quiero mencionar que no está limitado a las herramientas de desarrollo con eso. Puede utilizar un complemento de navegador para bloquear solicitudes. En este caso, no es necesario que las herramientas de desarrollo se mantengan abiertas cada vez solo por eso.

Pero espero que en el futuro obtengamos algo simple como:

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

HRM apesta. Trae dificultades más a menudo que beneficios (por ejemplo, cuando algunas partes del código se recargan en caliente mientras que otras no lo hacen, lo que provoca un estado inconsistente).

Si bien la sugerencia de http://localhost:3000/_next/on-demand-entries-ping?page=/xxx , solo que ahora son errores.

No aceptable para depuración: - /

Seguro que me encantaría tener

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

¿Quizás alguien podría escribir un complemento para esto?

@gihrig puede filtrar estos errores con el menú contextual de la consola (haga clic con el botón derecho en el error):

@arunoda ¿ Algún progreso en esto? Tengo un problema con los proptypes de HMR e inmutablejs, muy frustrante. Ver: https://github.com/facebook/prop-types/issues/221

Mi solución fue habilitar request blocking y luego agregar la solicitud on-demand-entries-ping a la lista de solicitudes bloqueadas. Espero que ayude a otros a quienes no les gusta HMR tanto como a mí.

Para deshabilitar la recarga de módulos en caliente (HMR) en Next.js v7 +, agregue esto a su archivo next.config.js :

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

Esto deshabilitará la reconstrucción en caso de cambio, lo que a su vez hará que el navegador nunca "vea" ningún cambio y, por lo tanto, no recargará nada. Esto significa que Next.js no se recompilará con los cambios . Deberá reiniciar el servidor next.js cada vez que haya un cambio, luego actualice su navegador.

Para obtener una solución que obligue a recargar toda la página en cada cambio, consulte este comentario a continuación .

FWIW fusionará esto pronto: https://github.com/zeit/next.js/pull/4508

Para una solución que siempre recargará la página en los cambios , puede crear 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
});

Estoy como un 80% seguro de que esto se romperá en el futuro.

Es un truco horrible, pero la única forma en que pude evitar un error que haría que la pestaña del navegador consumiera> 100% de CPU y luego se bloqueara en Chrome en cada recarga en caliente.

Con suerte, para cuando se rompa el truco, habrá una solución oficial o se solucionarán los errores mencionados en este problema 👍

La razón por la que quiero deshabilitar HMR es que el panel DevTools / Applications / Cookies (Chrome Windows) pierde el foco a medida que escribe porque las actualizaciones de HMR siguen sucediendo en segundo plano. Sospecho que este sería el caso incluso si le dije a webpackDevServer que ignorara todos los archivos. La conexión de websocket todavía se haría en segundo plano y creo que es esta conexión la que destruye el panel de cookies.

El punto es: una solución ideal debe desactivar HMR por completo. ¡Gracias!

Es lamentable que no pueda simplemente agregar esto a su next.config.js

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

Esta opción le indica al módulo que opere en modo 'perezoso', lo que significa que no se recompilará cuando los archivos cambien, sino en cada solicitud. Suena como algo que muchos de nosotros estamos esperando sin tener que ir tan lejos como las soluciones de @jesstelford .

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

Cuando intento esto en next 7.0.2 , obtengo el siguiente error:

Tuve la oportunidad de trabajar con un proyecto de Create React App hoy.

Creo que la raíz de este problema de HMR no es que HMR sea malvado sino la forma en que se implementa.

En pocas palabras, tener al cliente sondeando periódicamente el servidor no es lo ideal.

A partir de una observación superficial, parece que CRA usa una conexión de socket que solo se comunica con el cliente cuando un archivo ha cambiado, luego el cliente vuelve a cargar la página. Este esquema también da como resultado una actualización del navegador más rápida porque la operación no depende del siguiente intervalo de sondeo.

CRA es de código abierto . Sería genial si alguien con el tiempo y el interés pudiera profundizar en la actualización del HMR de Next para seguir el modelo CRA (y deshabilitarlo fácilmente también, por supuesto :-)

@gihrig, es probable que haya algunas razones diferentes por las que las personas buscan deshabilitar HMR.

Tengo entendido que react-hot-loader requiere ciertas suposiciones sobre cómo se escribe su aplicación, cómo se modela el estado y la ausencia de una identidad de objeto significativa. Estas suposiciones generalmente son válidas para una aplicación basada en redux escrita correctamente, pero pueden no ser válidas para aplicaciones que han sido diseñadas con otros enfoques. Estoy de acuerdo en que el problema no es que HMR sea malo, es solo que no es una herramienta genérica. Esto crea cierta disonancia en el contexto de un marco que, por lo demás, es agnóstico sobre estas decisiones de diseño.

Cambiar de sondeo a websockets es probablemente una buena idea, pero el sondeo no es “la raíz del problema” o, más bien, no está relacionado con al menos algunos de los problemas con los que se ha encontrado la gente aquí.

Tenga en cuenta que los dos últimos 2 comentarios hacen suposiciones incorrectas:

• Next.js no usa react-hot-loader, vuelve a renderizar el árbol de componentes cuando se emite un cambio
• Next.js no realiza sondeos para recibir cambios, realiza sondeos para marcar qué páginas aún se están viendo, en canary, esto se ha cambiado a un websocket solo para que el usuario no vea el sondeo en sus herramientas de desarrollo. Para expandir aún más este HMR funciona utilizando una conexión de fuente de eventos, lo que significa que el servidor envía eventos (en el cambio de archivo) al navegador

@timneutkens Es genial escucharlo, gracias. Sin embargo, no fue una suposición incorrecta, era información desactualizada. La RHL estaba en uso cuando comenzamos a usar Next y fue la causa de los problemas que encontramos lo que me llevó a comentar originalmente en este hilo. Sin embargo, no he visto ningún problema relacionado con HMR al usar Next en un tiempo.

De hecho, ¡ahora podemos ejecutar nuestro desarrollador de compilación ES2017!

Después de 2 años de personas quejándose de HMR, ¿todavía no hay una forma oficial de desactivarlo?

¿Por qué este registro GET / _next / on-demand-entries-ping? Page = / en mi aplicación NON next.js?

- auto-resuelto: tuve que comentar el logger app.use. (morgan (dev)) lo extraño es que Morgan está instalado en una aplicación diferente sin next.js, así que algo está sucediendo con esto siendo registrado por Morgan, quiero saber por qué sucede esto. Esto no sucedía antes de instalar next.js en un proyecto diferente.

Vuelve a abrir el problema definitivamente no está resuelto.

+1