Next.js: Módulo no encontrado: no se puede resolver 'fs'

Creado en 5 jul. 2019  ·  13Comentarios  ·  Fuente: vercel/next.js

Informe de error

Describe el error

Estoy usando el paquete npm de búsqueda popular, que tiene la ruta de ubicación como dependencia. locate-path requiere fs dentro de su código.

Cuando intento ejecutar mi aplicación, aparece el siguiente mensaje de error:

[ error ] ./node_modules/locate-path/index.js
Module not found: Can't resolve 'fs' in 'C:\...\node_modules\locate-path'
Could not find files for /index in .next/build-manifest.json
Promise { <pending> }
ModuleNotFoundError: Module not found: Error: Can't resolve 'fs' in 'C:\...\node_modules\locate-path'
    at factory.create (C:\...\node_modules\webpack\lib\Compilation.js:823:10)
    at factory (C:\...\node_modules\webpack\lib\NormalModuleFactory.js:397:22)
    at resolver (C:\...\node_modules\webpack\lib\NormalModuleFactory.js:130:21)
    at asyncLib.parallel (C:\...\node_modules\webpack\lib\NormalModuleFactory.js:224:22)
    at C:\...\node_modules\neo-async\async.js:2830:7
    at C:\...\node_modules\neo-async\async.js:6877:13
    at normalResolver.resolve (C:\...\node_modules\webpack\lib\NormalModuleFactory.js:214:25)
    at doResolve (C:\...\node_modules\enhanced-resolve\lib\Resolver.js:184:12)
    at hook.callAsync (C:\...\node_modules\enhanced-resolve\lib\Resolver.js:238:5)
    at _fn0 (eval at create (C:\...\node_modules\tapable\lib\HookCodeFactory.js:33:10), <anonymous>:15:1)
    at resolver.doResolve (C:\...\node_modules\enhanced-resolve\lib\UnsafeCachePlugin.js:37:5)
    at hook.callAsync (C:\...\node_modules\enhanced-resolve\lib\Resolver.js:238:5)
    at _fn0 (eval at create (C:\...\node_modules\tapable\lib\HookCodeFactory.js:33:10), <anonymous>:15:1)
    at hook.callAsync (C:\...\node_modules\enhanced-resolve\lib\Resolver.js:238:5)
    at _fn0 (eval at create (C:\...\node_modules\tapable\lib\HookCodeFactory.js:33:10), <anonymous>:27:1)
    at resolver.doResolve (C:\...\node_modules\enhanced-resolve\lib\DescriptionFilePlugin.js:42:38)

Creé un problema en el repositorio de ruta de localización y han confirmado que el problema no es con ellos, pero probablemente con el paquete web. No uso webpack en mi aplicación, por lo que el problema debe surgir del uso de webpack de Next.js.

Reproducir

Clone https://github.com/TidyIQ/nextjs-issue y ejecute npm run dev .

Comportamiento esperado

Sin problema

Información del sistema

  • SO: Windows 10
  • Versión de Next.js: 8.1.1-canary.67

Comentario más útil

Actualización para Next.js moderno (9.4+)

Puede utilizar de forma segura fs dentro de getStaticProps o getServerSideProps , no se requiere configuración adicional . Asegúrese de hacer referencia a la variable en el ciclo de vida de sus datos para que se elimine correctamente el árbol.

¡Puede usar esta herramienta para aprender visualmente cómo funciona!

Si todavía está construyendo sobre una versión heredada de Next.js con getInitialProps , lea a continuación 👇


El código proporcionado no es válido; este archivo nunca estaría disponible en el lado del cliente durante la renderización:

https://github.com/TidyIQ/nextjs-issue/blob/aef67b12d91d299d0978550005a40cbb34f74b71/pages/index.js#L5

Recuerde, solo puede realizar operaciones relacionadas con FS mientras esté _en el servidor_. Esto significa que no puede usar fs mientras renderiza.

Si usa fs , asegúrese de que esté solo dentro de getInitialProps .

También es posible que deba crear un archivo next.config.js con el siguiente contenido para que se compile el paquete del cliente:

module.exports = {
  webpack: (config, { isServer }) => {
    // Fixes npm packages that depend on `fs` module
    if (!isServer) {
      config.node = {
        fs: 'empty'
      }
    }

    return config
  }
}

Todos 13 comentarios

Actualización para Next.js moderno (9.4+)

Puede utilizar de forma segura fs dentro de getStaticProps o getServerSideProps , no se requiere configuración adicional . Asegúrese de hacer referencia a la variable en el ciclo de vida de sus datos para que se elimine correctamente el árbol.

¡Puede usar esta herramienta para aprender visualmente cómo funciona!

Si todavía está construyendo sobre una versión heredada de Next.js con getInitialProps , lea a continuación 👇


El código proporcionado no es válido; este archivo nunca estaría disponible en el lado del cliente durante la renderización:

https://github.com/TidyIQ/nextjs-issue/blob/aef67b12d91d299d0978550005a40cbb34f74b71/pages/index.js#L5

Recuerde, solo puede realizar operaciones relacionadas con FS mientras esté _en el servidor_. Esto significa que no puede usar fs mientras renderiza.

Si usa fs , asegúrese de que esté solo dentro de getInitialProps .

También es posible que deba crear un archivo next.config.js con el siguiente contenido para que se compile el paquete del cliente:

module.exports = {
  webpack: (config, { isServer }) => {
    // Fixes npm packages that depend on `fs` module
    if (!isServer) {
      config.node = {
        fs: 'empty'
      }
    }

    return config
  }
}

Tengo el mismo problema en mi instalación local, prácticamente vainilla, sin embargo, en los ejemplos de nextjs esto no parece ser un problema
https://github.com/zeit/next.js/tree/5787cbd9de33ea9add7cadeb04689b0d4b02976d/examples/blog-starter

¿Qué hace que funcione allí sin modificar el archivo de configuración?

Solo use fs en getStaticProps / getServerSideProps ya que se eliminan del paquete del navegador.

Descubrí cuál era el problema. Si importo una función que usa fs , pero no ejecuto / uso la función dentro de getStaticProps, terminará incluyéndose en el paquete del navegador. Una vez que se hace referencia a la función dentro de getStaticProps, dejará de aparecer en el paquete del navegador.

Supongo que hay una lógica oculta que elimina las importaciones utilizadas en getStaticProps pero no utilizadas en la exportación principal. Pasé algunas horas depurando hasta que pude reproducir, tal vez valga la pena tener una nota al margen en algún lugar de los documentos :)

¿No es la lógica oculta solo el árbol del paquete web temblando? Tiene sentido cuando lo piensa, Next no importa getStaticProps en el paquete del navegador, por lo que elimina la función importada utilizada en él.

Si no lo hace referencia en ningún lugar, supongo que el paquete web considera que lo importó para efectos secundarios, por lo que aún lo incluye en cada paquete.

¿No es la lógica oculta solo el árbol del paquete web temblando? Tiene sentido cuando lo piensa, Next no importa getStaticProps en el paquete del navegador, por lo que elimina la función importada utilizada en él.

Si no lo hace referencia en ningún lugar, supongo que el paquete web considera que lo importó para efectos secundarios, por lo que aún lo incluye en cada paquete.

No, la agitación del árbol de paquetes web no es lo suficientemente sofisticada para sacudir estas exportaciones de esa manera. La agitación de árboles getStaticProps / getServerSideProps / getStaticPaths es manejada por este complemento personalizado de Babel que creamos: https://github.com/vercel/next.js/blob/canary/packages/next/build/babel/plugins/next-ssg-transform .ts

Oh, gracias por el puntero, parece que sobreestimé el paquete web :)

¿Alguna razón por la que esto estaría sucediendo desde _dentro de_ getServerSideProps ?

Hola a todos. Como @aloukissas , tengo el mismo problema cuando uso dotenv dentro de mi index.js getStaticProps() . Se resuelve al agregar el archivo next.config.js como se muestra en el comentario inicial de @Timer .

¿Alguna pista de por qué está sucediendo esto? Estoy perdiendo Next.js v.9.4.0

¡Gracias!

Tuve este error mientras usaba fast-glob .

Usé esta gran herramienta para comprender el código que se incluye en el lado del cliente.

Resultó que estaba importando una variable de un archivo que usa fast-glob que usa internamente fs pero no estaba usando la variable en ningún lugar dentro de getStaticProps por lo que los archivos importan fast-glob no fueron eliminados.

Un ejemplo:

mdxUtils.js

import glob from 'fast-glob'
import path from 'path'

export const BLOG_PATH = path.join(process.cwd(), 'posts')
export const blogFilePaths = glob.sync(`${BLOG_PATH}/blog/**/*.mdx`)

index.js

import { BLOG_PATH, blogFilePaths } from './mdxUtils'

export const getStaticProps = () => {
  const posts = blogFilePaths.map((filePath) => {
    ...
  }
  return { props: { posts } }
}

Como puede ver, no estoy usando BLOG_PATH en ningún lugar de index.js pero sigo importándolo. Solo estoy usando blogFilePaths por lo que me dio este error.

Para más contexto → https://github.com/vercel/next.js/discussions/17138

Gracias @ deadcoder0904 este es mi código:

import Layout from '../components/template'
import Main from '../components/main'
import Menu from '../components/menu'
import 'dotenv/config'

export async function getStaticProps () {
  const avatarLocation = process.env.AVATAR_URL
  const avatarTitle = process.env.AVATAR_TITLE

  return {
    props: {
      avatarLocation,
      avatarTitle
    }
  }
}

export default function RenderMainPage ({ avatarLocation, avatarTitle }) {
  return (
    <Layout
      avatarURL={avatarLocation}
      topLeft={<Menu />}
      middle={<Main avatarURL={avatarLocation} avatarTitle={avatarTitle} />}
    />
  )
}

La herramienta que mencionas muestra que import 'dotenv/config' está incluida en el código del cliente, y probablemente eso está haciendo que aparezca el error. Lo que pasa es que lo necesito para leer las variables env.

Probablemente haya otra manera mejor de hacerlo, todavía estoy aprendiendo Next.js :)

@ ig-perez A partir de Next v9.4, tienen una forma incorporada de cargar variables de entorno → https://nextjs.org/docs/basic-features/environment-variables

Le sugiero que lea los documentos para encontrar la solución :)

Eso es increíble, me perdí esa parte de los documentos, ¡gracias! Actualizaré mi código 👍🏽

¿Fue útil esta página
0 / 5 - 0 calificaciones