@baldurh C'est en effet très rare, lorsque vous utilisez des plates-formes comme Now, seul le dossier dans lequel se trouve l'application Next.js est déployé, c'est mieux ainsi car sinon, vous devez d'abord connaître tous les modules externes. 2 meilleures alternatives sont:

• Tout déplacer vers une seule application Next.js
• Utilisez des packages lerna ou privés npm ou similaires

@lfades merci pour la réponse. Aucune de ces options ne nous est disponible et nous ne déployons pas sur Now ou quelque chose de similaire. Nous avons utilisé des espaces de travail de fil au départ, mais nous avons ensuite intégré bazel et cela ne joue pas très bien avec la nature symbolique des espaces de travail de fil. Les packages Npm signifient que nous ne pouvons pas développer les modules partagés aussi vite que nous le souhaitons. C'est juste trop de frais généraux.

@baldurh Je next-i18next car nous avons des applications NextJs imbriquées comme exemples. Avez-vous trouvé une solution de contournement?

@isaachinman Nous ne l'avons pas fait. Nous n'avons pas encore réussi à mettre à niveau vers 9.x pour d'autres raisons, donc je ne l'ai pas étudié. Quelqu'un a-t-il une idée de l'endroit où le code affectant cela pourrait être? J'aimerais mieux comprendre le problème.

Je n'ai pas encore eu le temps de creuser là -dedans , mais si quelqu'un a besoin d'une repro: cd dans examples/simple et mettez à niveau la version NextJs vers> = 9.0.6.

Il est actuellement sur la version 9.0.3, il s'agit donc techniquement d' un changement radical sur un patch.

J'ai eu une erreur similaire récemment et j'ai dû passer à la version 9.0.5 (et React 16.8.x). J'ai en quelque sorte réduit le problème que j'ai vu à l'utilisation de MDX par Next, mais je n'ai pas de détails concrets au-delà de cela.

J'ai creusé le même problème avec un assez gros projet basé sur Next & next-i18next.

J'ai vu que cette erreur peut être générée par 3 raisons:

1. Versions react & react-dom mal alignées - non appliquées à mon application
2. 2 versions de react-dom importées - non appliquées à mon application
3. Mauvaise utilisation des hooks React - Je n'utilise pas de hooks mais certaines bibliothèques le sont, et il semble que cela fonctionne pour tout le monde.

La chose étrange est que cela ne se produit

@timneutkens @Timer désolé de vous avoir tagué là- dessus, mais j'aimerais avoir votre avis. Pensez-vous que c'est quelque chose qui pourrait être corrigé, avons-nous tous besoin de mettre en œuvre des solutions de contournement? C'est un gros bloqueur pour nous en ce moment. Merci.

Il semble que vous ayez un alias react mais pas react-dom . Pouvez-vous essayer ça?

@Timer Merci. J'ai essayé mais ça n'a eu aucun effet

J'ai pu résoudre ce problème tout à l'heure dans la repro en déplaçant d'un niveau les dépendances react et react-dom . J'ai juste poussé les changements si quelqu'un veut l'essayer. Je ne l'ai pas essayé sur notre projet actuel, mais j'espère que cela fonctionnera pour nous. Cela pourrait peut-être résoudre le problème de @isaachinman , @jaredcwhite et @felixmosh également?

Je @Timer obtenu ce travail dans notre projet , mais je devais aussi me assurer que je n'avais pas d' autres dépendances qui a installé react dans nos projets node_modules dossier. Dans notre cas, c'était lié au livre d'histoires ( yarn why react a beaucoup aidé 😄). Nous prévoyions de toute façon de déplacer le livre de contes vers un projet séparé, donc je pense que cette solution fonctionnera dans notre cas.

Ah oui. Les packages node_module publiés de manière incorrecte en seront la cause (avec des dépendances sur react(-dom|) au lieu de la dépendance des pairs).

J'ai pu résoudre ce problème tout à l'heure dans la repro en déplaçant d'un niveau les dépendances react et react-dom . J'ai juste poussé les changements si quelqu'un veut l'essayer. Je ne l'ai pas essayé sur notre projet actuel, mais j'espère que cela fonctionnera pour nous. Cela pourrait peut-être résoudre le problème de @isaachinman , @jaredcwhite et @felixmosh également?

Pouvez-vous nous expliquer les modifications que vous avez apportées à ce dépôt?

J'exécute npm ls react ou npm ls react-dom Je n'ai que ma prochaine application dans la liste.

@felixmosh Désolé, apparemment la poussée a échoué pour moi hier. Maintenant, les changements sont définitivement là 😅 J'ai déplacé react et react-dom du dossier app dans le dossier racine, alors vous devez maintenant faire yarn/npm install dans les deux app et le dossier racine avant d'exécuter le app . J'espère que c'est assez clair.

Nous allons devoir apporter quelques modifications à notre système de construction pour que cela fonctionne en production, donc cette solution est encore un peu compliquée pour nous 😝

Merci pour l'explication, j'attendrai la prochaine équipe pour le résoudre, ça semble un peu bizarre de mettre deps de réaction à la racine de mon mono-repo ...

@felixmosh Ouais, je suis plutôt d'accord avec toi. Cependant, si vous utilisez quelque chose comme des espaces de travail de fil, c'est exactement ce que cet outil fera. Si vous avez la même dépendance dans deux projets ou plus, les dépendances seront hissées à la racine. C'est bien car cela garantit que vous avez la même version des dépendances dans tous vos projets. Mais si vous n'avez pas un outil comme celui-là, vous devrez le gérer vous-même, ce qui est en effet un peu gênant. Je suis d'accord que la meilleure solution serait que l'équipe Next.js jette un œil et résout cela pour nous tous 😇🙏🏻

Rencontrer le même problème et amener react et react-dom un niveau et exécuter le serveur à partir de la racine est la seule solution de contournement qui fonctionne actuellement sur 9.1.5. Lien https://github.com/facebook/react/issues/13991 et https://github.com/facebook/react/issues/15315#issuecomment -479802153 pour référence car j'ai trouvé ces liens avant ce numéro.

Salut une mise à jour sur ce problème? Nous avons un monorepo et nous rencontrons ce problème précis.

Rencontrez le même problème.
La v9.0.5 fonctionne très bien avec les hooks pour les composants importés en dehors du rootFolder.

À partir de 9.0.6 jusqu'à 9.1.6-canary.5 ont les mêmes problèmes.

Le problème se produit uniquement du côté serveur. Si SSR est désactivé (par exemple, chargez un composant externe via dynamique ), tout fonctionne comme prévu pour les versions> = 9.0.6.

@nodkz c'est un problème avec la résolution du package react, donc cela ne se produit que dans node.

@Timer ce problème est passé à l'étape "suivante" pour environ 6 versions, cela m'empêche de mettre à jour vers la dernière version.

J'ai perdu toute une journée de temps dans un logement dessus, je ne sais pas quelle est la source du problème, j'ai même essayé la solution de contournement (qui n'a pas fonctionné).

Avez-vous besoin d'aide pour étudier une direction?
Avez-vous des instincts à ce sujet?
Pourquoi cela se produit-il uniquement sur la version de production?
Qu'est-ce qui a été changé de 9.0.5 à 9.0.6 qui pourrait être lié à cela?

Merci 🙏🏼

Je pense que j'ai trouvé le problème !!!
Je pense que c'est une combinaison de 2 choses:

1. utilisation de sym-link pour node_modules
2. i18next / react-i18next n'étaient pas externes dans les bundles de serveurs !!
   
   Dans mon cas, quand il explose en production, il se plaint sur i18next useTranslation hook ...

J'ai donc étudié la raison pour laquelle il y a des modules de nœuds à l'intérieur des bundles de serveurs (la meilleure pratique pour les bundles de serveurs est de les rendre externes).

J'ai vu que next a quelques exceptions pour la prochaine lib (pourquoi?), Le plus drôle est que cette regex attrape toutes les libs qui se terminent par next/dist/ , comme le fait i18next & react-i18next !!

Donc, si vous changez ceci:

res.match(/next[/\\]dist[/\\]/) 

dans

res.match(/[/\\]next[/\\]dist[/\\]/) 

Le bundle du serveur exclura toutes les bibliothèques qui ne sont pas next & se termine par next/dist , et il a résolu le problème!

Pour moi, le problème principal est la nouvelle façon dont les demandes sont résolues: https://github.com/zeit/next.js/blob/canary/packages/next/build/webpack-config.ts#L446

Puisque nous avons des composants en dehors de la racine du projet, la résolution de la requête lèvera une erreur qui se traduira par le regroupement de react dans les morceaux de serveur. Et c'est pourquoi nous obtenons l'erreur Invalid hook call sur le serveur.

@baldurh context dans cette expression que vous avez liée est fournie par webpack, et est différente de la racine de compilation (votre répertoire de projet).
C'est toujours le répertoire du fichier qui émet le require.

Droite. J'ai corrigé cela pour que cela fonctionne pour nous pour le moment. Je pense que nous allons éventuellement changer la structure du code afin que les dépendances soient partagées au niveau du répertoire supérieur. Cependant, même si react est disponible dans le dossier externe (en dehors de la racine), j'ai toujours l'erreur.

J'essaie d'utiliser un package lié et je rencontre le même problème. Malheureusement, aucun des correctifs de https://github.com/facebook/react/issues/13991 ne fonctionne 🙁

Je rencontre également le même problème avec une bibliothèque de composants liée symboliquement avec yarn link . Cela a bien fonctionné jusqu'à v9.0.6-canary.4 et maintenant je suis dans la même position que certains autres commentateurs et je ne peux pas mettre à niveau au-delà de cela .. J'ai signalé le changement à ce PR https://github.com/zeit /next.js/pull/8739

Ma bibliothèque de composants utilise react , react-dom et styled-components . La configuration pour cela est la suivante

• Ajout des packages en tant que devDependencies et les inclus dans peerDependencies
• Ajout des packages en tant qu'externes dans ma configuration webpack
• Ajout d'alias de résolution à ces packages dans ma prochaine configuration
• Transpilé le module de bibliothèque de composants avec next-transpile-modules

Mettre à jour

J'ai pu résoudre ce problème en incluant ces modules dans les serveurs externes. Merci à @HosseinAgha dans ce commentaire https://github.com/martpie/next-transpile-modules/issues/50#issuecomment -558318688

if (isServer) {
  config.externals = [
    'react',
    'react-dom',
    'styled-components',
    ...config.externals
  ]
}

Je vois exactement les mêmes problèmes, aucune des solutions de contournement n'a fonctionné pour moi jusqu'à présent.

Mon package fonctionne si je le publie et l'installe (et utilise resolver.alias dans mon next.config.js).

Mais exécuter une compilation de développement avec le package lié via yarn link @mypackage entraîne toujours une erreur de hook non valide.

J'ai également pu le faire fonctionner en modifiant node_modules/dist/build/wepack-config.js et en commentant les lignes ajoutées dans https://github.com/zeit/next.js/pull/8739

Ce que je vois si je consigne baseRes et res, c'est que la condition if se déclenche comme:

• /myApp/node_modules/react/index.js! == /myApp/node_modules/myPackage/node_modules/react/index.js
• d'après ce que je comprends, cela se déclenche si le chemin n'est pas le même, même le fichier / la version est 100% identique

Mettre à jour:

Nous avons réussi à contourner le problème en convertissant notre package pour utiliser des espaces de travail yarn (même si notre dépôt ne contient qu'un seul package).
Nous avons déplacé notre code de ./src vers ./package/our-package-name/src et configuré yarn workspaces => https://classic.yarnpkg.com/en/docs/workspaces/

Cela permet de contourner le problème car cela élèvera les dépendances courantes au niveau supérieur. Le dossier ./node_modules et ./package/our-package-name/node_modules resteront largement vides.

Alors maintenant, lorsque nous lierons notre package, nous n'utiliserons plus une deuxième version de react (car il n'est pas présent dans notre dossier packages node_modules) et tout fonctionne comme il se doit.

J'ai le même putain de problème. ¬¬ '

Nous nous effondrons généralement en jurant car c'est contre le code de conduite.

Désolé, j'étais en colère contre ce bug. En fait, j'aime trop le Next.JS. Mais personne ne peut l'utiliser car ce problème est ennuyeux.

Nous sommes confrontés à ce problème lorsque nous travaillons avec des packages locaux externes et next-transpile-modules .

Comme nous voulons nous en tenir à la dernière version de Next.js, je vais essayer de soumettre un correctif à Next.js si je trouve la cause racine.

Je suis confronté au même problème, après l'installation de [email protected]
Mes dépendances sont [email protected] , [email protected] , [email protected] et bien sûr beaucoup d'autres libs (mais tout fonctionnait avant d'installer next-i18next). Si quelqu'un a une solution de contournement, cela pourrait être génial: +1:

Merci d'avoir publié ce problème, j'ai également eu des problèmes avec la liaison symbolique de notre package de système de conception (bibliothèque de composants de réaction). Nous le transpilons également en utilisant https://github.com/martpie/next-transpile-modules.

Le correctif suggéré ici a fonctionné pour nous:

• Créez un lien symbolique entre votre bibliothèque et votre dossier node_modules (nous l'avons fait avec notre propre utilitaire au lieu de npm link mais cela devrait être fondamentalement le même)
• Ajoutez quelque chose comme ce qui suit à votre next.config.js :

// next.config.js
const nextConfig = {
    webpack: (config, options) => {
        // modify the `config` here

        if (options.isServer) {
            config.externals = ["react", ...config.externals];
        }
        config.resolve.alias["react"] = path.resolve(__dirname, ".\\node_modules\\react");

        return config;
    },
};
// more plugins etc...

Notre solution alternative qui ne nécessite aucune configuration

• Faites un lien symbolique sur tout sauf le node_modules de votre package. J'ai créé mon propre utilitaire pour cela peut peut-être le poster sur github.

Mais ce serait bien de voir cela corrigé dans NextJS, j'ai passé tellement de temps à essayer de comprendre pourquoi l'alias webpack fonctionnait pour tous mes projets non NextJS :)

PS. Je n'ai aucune idée de la façon dont cela affecterait une version de production, mais nous ne l'utiliserions que pendant le développement

if (options.isServer) {
            config.externals = ["react", ...config.externals];
        }

react est déjà externe côté serveur.

config.resolve.alias["react"] = path.resolve(__dirname, ".\\node_modules\\react");

Cela ne résoudra pas le problème.

Comme dit précédemment, ce problème est lié à vos dépendances en fonction de react alors qu'ils devraient avoir un peerDependency sur react (et react-dom s'ils en ont besoin).

@timneutkens

Eh bien non ce n'est pas toujours le cas. Je suis sûr que j'ai react et react-dom en tant que dépendances entre pairs. Le problème persiste cependant si, par exemple, vous créez un lien symbolique entre votre bibliothèque et un projet nextjs. Ce qui se passe alors, c'est que vous aurez un dossier node_modules dans votre bibliothèque (du moins si vous avez déjà exécuté npm i ou npm link dans ce dossier de bibliothèque).

Lorsque react est résolu à partir de ce dossier de bibliothèque, il sera résolu par celui de ce dossier node_modules et vous obtiendrez deux copies de react causant le problème. Si je supprime le dossier node_modules dans ma bibliothèque ou que je l'installe en utilisant autre chose que npm link alors oui ofc cela fonctionne (si vous utilisez des dépendances homologues ou exactement la même version de réaction).

Donc, pour résoudre ce problème pendant le développement, vous voulez pouvoir réagir aux alias pour forcer tout le monde à utiliser la même version. En raison des problèmes mentionnés ici, cela n'a aucun effet dans la version actuelle de NextJS sans ajouter la partie config.externals ... (du moins pour moi), probablement comme les gens l'ont mentionné ici à cause d'un changement comme indiqué ici # 8739?

Un problème similaire m'arrive mais (potentiellement) à cause de la bibliothèque material-ui (comme indiqué dans # 10162), ma solution temporaire pour l'instant consistait simplement à ajouter npm run clean dans mon preserve et dev scripts comme indiqué ici:
https://github.com/zeit/next.js/issues/10162#issuecomment -612501431

@timneutkens Je comprends que le vrai problème

@ ryan-0 Avez-vous une configuration spéciale? Serait-il surpris que le matériel Ui ne soit pas répertorié comme un peer dep? Par exemple, utilisez-vous une très ancienne version de React ou un lien symbolique?

pas de configuration spéciale .. pas de lien symbolique et de réaction 16.13.1 -> nous avons d'autres déps qui pourraient être à l'origine du problème, mais au moins selon cette repro, il semble peut-être lié à material-ui / core (que nous utilisons également):
https://github.com/zeit/next.js/issues/10162

@ ryan-0 y a-t-il un dossier node_modules avec react dans votre dossier material-ui?

Est-ce que commence également à fonctionner après l'exécution de la déduplication npm?

non, il ne semble pas qu'il y ait un dossier de nœuds imbriqués, c'est pourquoi je ne sais pas comment le bogue se produit. et non npm dedupe n'a pas fonctionné :(

Curieusement, l'utilisation de resolve.alias ne semble pas affecter les packages en dehors de la racine du projet.

Voici mon fichier next.config.js :

const path = require('path')

module.exports = {
  webpack: config => {
    const { alias } = config.resolve || {}
    alias.react$ = path.resolve('node_modules/react')
    alias['react-dom$'] = path.resolve('node_modules/react-dom')

    config.resolve = {
      ...config.resolve,
      alias,
    }

    return config
  }
}

J'utilise yarn link avec un package local qui existe dans un monorepo Lerna. Son node_modules ne contient pas une copie de react , mais la racine de monorepo fait. Je ne m'attendrais pas à ce que cela fasse une différence tant que resolve.alias est utilisé, mais ce n'est malheureusement pas le cas. Après avoir supprimé la copie de react de la racine monorepo, j'obtiens maintenant une erreur Cannot find module 'react' la place.

Quelqu'un a-t-il trouvé une bonne solution pour cela?

J'ai une prochaine bibliothèque liée que j'utilise next-transpile-modules pour l'ajouter à mon projet «consommateur». J'ai ajouté l'alias react dans mon next.config.json comme mentionné dans leurs documents, mais ce n'était pas suffisant. J'obtiens toujours l'erreur de dépendances dupliquées pour React.

Vous pouvez essayer d'utiliser relative-deps par @mweststrate

Quelqu'un a-t-il trouvé une bonne solution pour cela?

J'ai une prochaine bibliothèque liée que j'utilise next-transpile-modules pour l'ajouter à mon projet «consommateur». J'ai ajouté l'alias react dans mon next.config.json comme mentionné dans leurs documents, mais ce n'était pas suffisant. J'obtiens toujours l'erreur de dépendances dupliquées pour React.

Oui, voir mon message ci-dessus, vous devez ajouter la partie config.externals dans mon exemple, puis l'alias recommence à fonctionner

@johot J'ai essayé votre solution mais cela n'a pas vraiment fonctionné pour moi. J'ai commencé à avoir des erreurs étranges, mais principalement celle-ci: cannot destructure property 'query' of 'Object(...)(...)' as it is null après avoir essayé votre solution. L'objet considéré comme nul dans ce cas est le useRouter de next/router .

@aleclarson Merci pour le tuyau. Je vais essayer si je ne peux pas le faire fonctionner avec la prochaine configuration. L'utilisez-vous actuellement?

Si vous utilisez next-transpile-modules et Yarn, la solution est assez simple: https://github.com/martpie/next-transpile-modules#i -have-trouble-with-duplicated-dependencies-or-the -invalid-hook-call-error-in-react

Si vous utilisez npm , je cherche toujours moi-même une solution: c

Ok, donc ma solution finale était de migrer de yarn link à yalc . J'ai une tâche gulp qui surveille les changements de fichiers et copie les fichiers dans mon dossier dist , puis envoie les modifications dans le magasin yalc.

Dans mon 'consommateur' j'ai modifié le tsconfig.json pour résoudre les chemins comme ceci:

 "paths": {
      "~/*": ["/src/*"],
      "my-library/*": ["./node_modules/my-library/dist/*"]
    },

et dans le next.config.js j'ai ajouté ce qui suit:

 experimental: {
      jsconfigPaths: true, // enables it for both jsconfig.json and tsconfig.json
    }

Ensuite, vous pouvez résoudre les chemins en fonction du tsconfig.json paths . Plus d'infos ici .

En bref: la combinaison de yalc + next-transpile-modules a beaucoup amélioré ma configuration de développement local. Pas de dépendances en double et d'erreurs étranges. Le comportement d'ajout direct du module en utilisant yarn add et de liaison du module avec yalc est à peu près le même.

Si vous utilisez une bibliothèque liée localement qui dépend de styled-components , reportez-vous à ceci: https://styled-components.com/docs/faqs#linking -in-an-ssr-scenario

En server/index.js :

const moduleAlias = require('module-alias');
moduleAlias.addAlias('styled-components', path.join(__dirname, '../node_modules/styled-components'));

Mais nous devions également ajouter ce qui suit dans next.config.js :

config.resolve.alias['react'] = path.resolve(__dirname, './node_modules', 'react');
config.resolve.alias['react-dom'] = path.resolve(__dirname, './node_modules', 'react-dom');
config.resolve.alias['prop-types'] = path.resolve(__dirname, './node_modules', 'prop-types');
config.resolve.alias['styled-components'] = path.resolve(__dirname, './node_modules', 'styled-components');

J'espère que cela aide.

Testé avec:

Suivant: 9.3.5
Réagir: 16.13.1
styled-components: 5.1.0

Folks, solution simple, supprimez votre version globale de react, next et react-dom en faisant:
npm remove -g react next react-dom

Folks, solution simple, supprimez votre version globale de react, next et react-dom en faisant:

npm remove -g react next react-dom

Je suis content que cela ait fonctionné pour vous, mais je doute que beaucoup de personnes dans ce fil aient ces dépendances installées globalement.

Pas seulement sur le Web!
réagir 16,9
natif de réaction 0,62
Fonctionnement sur Android
Peut-être le plus petit reproducteur de l'histoire?

import React, { Component, useState } from 'react';
import {
  AppRegistry,
} from 'react-native';

function hooker() {
  const [count, setCount] = useState(0)
}

class ClassA extends Component {
  constructor(props) {
    super(props)
    //hooker();  //Invalid hook call Error
  }
  componentDidMount(){
    //hooker();  //Invalid hook call Error
  }
  render() {
    hooker();  //Invalid hook call Error
    return (      
      null   
    );
  }
} 
export default function App(props) {
  //hooker();  //No problem
  return (
    <ClassA/>
  );
};

AppRegistry.registerComponent('default', () => App);

J'ai également rencontré ce problème et je l'ai combattu pour utiliser yarn au lieu de npm (avec npm cela ne fonctionnait pas) et en utilisant https://github.com/vercel/next.js/ issues / 9022 # issueecomment -616169466

Y a-t-il une solution à cela?

Juste complètement coincé avec la version 9.4.4.

Problème se produisant sur HOC pour les itinéraires privés ci-dessous. J'ai également essayé d'utiliser withRouter mais la même erreur est renvoyée sur le composant enveloppé à la place.

import { useRouter } from 'next/router'

function withPrivateRoute(WrappedComponent) {
const router = useRouter();                    //**** ERROR IS THROWN HERE *******
class WPR extends React.Component {
    componentDidMount(){
        console.log('wrappeed', WrappedComponent);
        // const { router } = this.props;
        const intendedRoute = router.pathname;
        // const isAdmin = !!cookies.get('isAdmin');
        // const isAuthenticated = !!cookies.get('username');
        const isAuthenticated = false;
        const isAdmin = false;
        if (!isAuthenticated) {
            router.push({
                pathname: '/login',
                query: { from: intendedRoute },
            });
        }
        if (
            isAuthenticated &&
            router.pathname.includes('admin') &&
            !isAdmin
        ) {
            router.push('/');
        }
    }

    render() {
        return ({ ...props }) => <WrappedComponent {...props} />;
    }
}
return WPR;
 }

  export default withPrivateRoute;

J'ai eu le même problème, j'ai donc dû retourner à ma branche précédente (où je supposais que ce problème n'était pas là) et ajouter le dernier fichier de code par fichier et j'ai constaté que le problème était

import { useToasts, AppearanceTypes } from 'react-toast-notifications';

export const showToast = (message: string, appearance: AppearanceTypes) => {
    const { addToast } = useToasts();
    addToast(message, {
        appearance,
    });
};

J'utilisais un service de toast et à chaque demande s'il y a une erreur showToast apparaît mais maintenant avec cette erreur, je ne pense pas que j'utiliserai ce service

Je peux confirmer que cela est lié au PR https://github.com/vercel/next.js/pull/8739 par @arcanis
Nous utilisons une configuration monorepo avec Rush et pnpm, ce qui élimine la raison pour laquelle le PR mentionné a été fusionné. Cela signifie également que le point que @timneutkens fait dans https://github.com/vercel/next.js/issues/9022#issuecomment -610255555 ne s'applique pas à nous, nous avons la structure suivante:

website
  dependencies: next, react, react-dom, library
library
  devDependencies: react, react-dom (for tests)
  peerDependencies: react, react-dom

Les library.devDependencies.(react|react-dom) sont des liens symboliques qui pointent vers les mêmes fichiers que les website.dependencies(react|react-dom) . Cependant, cela ressemble à ré[email protected] qui est utilisé dans https://github.com/vercel/next.js/blob/f98e38c9b634b85e6679e7b5f953a9d98074cfc3/packages/next/lib/resolve-request.ts#L16 ne suit pas le courant comportement par défaut de Node.js en préservant les liens symboliques.

Nous nous sommes retrouvés avec ce qui suit:

1. Configuration des modules next-transpile pour transpiler notre code en library
2. Définition de resolve.symlinks = true dans la configuration du webpack à l'intérieur de next.config.js
3. Manipulation des externes demandés au library à demander au library/node_modules (pour que la construction côté serveur résolve correctement les modules)
4. Commentant la ligne https://github.com/vercel/next.js/blob/f98e38c9b634b85e6679e7b5f953a9d98074cfc3/packages/next/build/webpack-config.ts#L601

Cela fonctionne comme prévu mais semble piraté, étant donné que Next.js alimente certains des sites Web importants comme celui d' Apple, est-il possible de s'attendre à un meilleur support pour les monorepos qui sont souvent utilisés pour gérer le code partagé dans ces grands projets?

J'ai joué avec ceux-ci et j'ai trouvé que, lorsque j'utilise un HOC, cela génère une erreur, mais si j'utilise un composant comme wrapper, cela fonctionne bien.

Si quelqu'un est intéressé, j'ai un dépôt où vous pouvez reproduire ceci: next-components-hooks-error

Test HOC - Génère une erreur

components/withPrivateRoute.js -> Composant d'ordre supérieur

import React, { useEffect } from 'react';
import { useRouter } from 'next/router';
const withPrivateRoute = WrappedComponent => {

    const router = useRouter();
    const [loading, setLoading] = useState(true);

    useEffect(() => {
        const user = localStorage.getItem('user');
        console.log(user);

        if (!user) {
            router.push('/login');
        } else {
            setLoading(false);
        }

    }, []);

    return ({ ...props }) => !loading && <WrappedComponent test={test} {...props}/>;
};

export default withPrivateRoute;

pages/hoc.js -> Ne fonctionne pas (page utilisant le HOC)

import React from 'react';
import withPrivateRoute from '../components/withPrivateRoute';

const HocTest = () => <p>Authorization HOC Test!</p>;

export default withPrivateRoute(HocTest);

Test des composants d'emballage

components/AuthLayout.js -> Composant (wrapper)

import React, { useState, useEffect } from 'react';
import { useRouter } from 'next/router';

const AuthLayout = ({ children }) => {

    const router = useRouter();
    const [loading, setLoading] = useState(true);

    useEffect(() => {
        const user = localStorage.getItem('user');
        console.log(user);

        if (!user) {
            router.push('/login');
        } else {
            setLoading(false);
        }

    }, []);

    return !loading && (
        <React.Fragment>
            {children}
        </React.Fragment>
    );
};

export default AuthLayout;

pages/wrapper.js -> Page utilisant le composant wrapper, ça marche

import React from 'react';
import AuthLayout from '../components/AuthLayout';

const WrapperTest = () => (
    <AuthLayout>
        <p>Authorization Wrapper Test!</p>
    </AuthLayout>
);

export default WrapperTest;

hey @Timer y a-t-il un progrès à ce sujet?

Je résolve mon problème en utilisant https://github.com/vercel/next.js/issues/9022#issuecomment -609969178 comme solution.
Mes problèmes étaient liés à l'utilisation de mon dépôt de bibliothèques et à yarn link avec mon dépôt d'applications
exemple
package.json

{
  "dependencies": {
    "next": "9.5.1",
    "myUILibrary": "git+ssh://[email protected]/MyRepo/library-web-ui.git#master",
    "react": "16.13.1",
    "react-dom": "16.13.1"
  }
}

et je yarn link myUILibrary à ma caisse locale MyRepo/library-web-ui qui a également react installé.

Merci beaucoup @johot pour avoir publié votre solution

5 🌟 sur 3 (oui! Toutes les étoiles et plus!)

Je peux confirmer la même expérience que @ wasd171 dans un monorepo Rush + PNPM. J'utiliserai juste ~9.4.4 dans l'intervalle.

J'ai exactement le même problème avec Rush + PNPM 👍

ok j'ai eu une erreur très stupide provoquant ce problème:

import React, { useState } from 'React';

Il devrait être r eact au lieu de R eact:

import React, { useState } from 'react';

Ouaip. Je vois cela aussi dans 9.5.x - La rétrogradation à 9.4.4 fonctionne - Vous pouvez également le reproduire avec le next-site

Je n'ai pas pu corriger cette erreur dans la version 9.5.2. Mais tout fonctionne parfaitement en 9.5.3 pour moi sans aucune astuce.

Je n'utilise pas pnpm.

J'ai parlé trop tôt. Je ne pense pas que cela fonctionne non plus avec 9.5.3.

Cela fonctionne de manière fiable en 9.5.3 pour moi maintenant. 🤷 Je ne sais plus ce qui se passe.

9.5.3 ne fonctionne pas pour moi - même erreur. J'utilise Rush + NPM. Existe-t-il une solution de contournement connue? (btw permet de mettre à jour le titre car il ne s'agit plus de 9.0.6)

Pour info, c'est l'une des raisons pour lesquelles mon organisation a décidé de passer de npm à yarn . Il joue juste (malheureusement) beaucoup mieux. Le déménagement est ennuyeux, mais nous sommes plutôt heureux maintenant.

Les modules transpilés avec des crochets ne fonctionnent pas non plus pour moi.

À propos, à toute personne rencontrant ce problème lors de l'utilisation de next-transpile-modules et npm , j'ai écrit une section FAQ qui explique le problème et les solutions potentielles: https://www.npmjs.com/package/ next-transpile-modules # i -have-trouble-with-duplicated-dependencies-or-the-invalid-hook-call-error-in-react

J'ai réussi à résoudre ce problème en ajoutant manuellement la résolution de version pour le fil dans la racine du projet. Donc, au lieu de déplacer toutes les dépendances de réaction vers la racine package.json , j'ai ajouté les lignes suivantes:

  "resolutions": {
    "react": "16.13.1",
    "react-dom": "16.13.1"
  }

Voir: https://classic.yarnpkg.com/en/docs/selective-version-resolutions/

Il convient de noter que dans mon cas, les builds locaux fonctionnaient alors que les builds sur Vercel rapportaient l'erreur Invalid hook call .

J'ai expérimenté un problème similaire dans _app.js avec une page fourre-tout dans Next 10

Hey,

Dans mon cas, j'avais transpilé des modules qui étaient également liés via npm link .

Les dépendances comme React doivent être incluses en tant que peerDependencies au lieu de dépendances normales car il en téléchargeait plusieurs instances. Donc, si vous rencontrez l'erreur de hooks non valide, essayez ces étapes:

1. Incluez votre module tiers en tant que dépendance dans votre projet principal.
2. Exécutez un npm install pour installer tous vos modules.
3. Ouvrez votre terminal / console et accédez au module, puis exécutez sudo npm link .
4. Revenez à votre projet principal et exécutez un npm link @example/project . Vous devriez voir une petite icône de flèche près de votre nom de module dans node_modules si vous utilisez Visual Studio Code.
5. Exécutez votre npm run dev .

Encore une fois, vous devez inclure React en tant que peerDependency au lieu d'une dépendance régulière dans votre @ exemple / projet.

J'espère que cela aide!

J'ai un monorepo avec un projet next.js à l'intérieur. Face au même problème avec un appel de hook non valide après l'installation de storybook . J'ai résolu le problème en suivant la suggestion de @aengl - j'ai ajouté le resolutions au niveau racine package.json :

"resolutions": {
  "react": "^17.0.1",
  "react-dom": "^17.0.1"
}

Je ne suis pas sûr que ce soit une bonne solution une fois que nous ajouterons plus de clients et de packages.