Monorepo Sliding methodology: Reference module Hot Update

Préface

Bien que monorepo J'ai beaucoup parlé avant,Les limites des choix technologiques ont également été explorées à plusieurs reprises,Mais avec le temps et les domaines de pratique、élargissement de l'échelle,Introspection：Quel est le point mental de plus en plus important？

Il ne fait aucun doute que： Mise à jour à chaud du module de référence

Qu'est - ce que “Mise à jour à chaud du module de référence” ：C'est toi qui monorepo Lors du développement du projet,Code de référence du sous - paquet transversal,Modifier les fichiers de code source d'autres sous - paquets,Pour pouvoir détecter automatiquement dans le projet en cours,Prise en charge des mises à jour à chaud,Donc vous n'avez pas besoin de reconstruire le produit de ce sous - paquet,Puis la page a été rafraîchie manuellement.

Nous allons explorer une sorte de trade off La solution de glissement de fil,Avant de lire,Notre lecteur par défaut a déjà Habile webpack Base Ou Développeur de cadres .

La solution

Tranpile Includes

Why not watch ?

Commencez par une question,Pourquoi pas? watch Mode pour démarrer ce sous - paquet,Et puis il peut changer lui - même,Reconstruction automatique des produits de construction？

1. Premièrement, il y a un retard dans le temps de construction.Si c'est tsc C'est bon,Si c'est rollup rebuild Le temps consacré à un seul document est encore plus insupportable;Ensuite, pour les grands sous - paquets sdk ,Le plus rapide tsc Tout près. 10s Heure,Sans oublier rollup C'est.

   Bien sûr.,On peut dire que esbuild Il suffit de résoudre le problème du temps de construction,Mais esbuild bundle C'est un seul fichier , Un seul changement de fichier signifie l'ensemble reload , Au lieu d'une partie hmr C'est, Il en va de même pour les dommages causés par le rafraîchissement global du projet principal , Imaginez que vous ayez ouvert un Modal Pop - up as, La prochaine fois que je rouvrirai （ Il n'y a pas de discussion ici unjs Un seul document de réflexion transpile ,Ce n'est pas le but de cet article）.

2. Deuxièmement, aucun changement de produit n'a été détecté . Parce que les sous - paquets sont liés à node_modules - Oui., En général, le côté cadre exclude Exclure,Pas d'écoute, Ainsi, même si le produit change, la page ne sera pas mise à jour à chaud .

Alors quelle est la solution , Si ça fait mal, concentrons - nous sur ce qui ,C'est évident., Comme il ne reconnaît pas , On va le faire manuellement webpack rule Les règles le placent dans nos limites .

Séparation des règles

Parce que tous nos codes de sous - paquets sont ts De, Il faut donc que ts Toutes les ressources entrent dans notre transpile Champ d'application, Il faut donc .js Et .ts Séparation des règles d'appariement des ressources ,Tous les .ts Les règles ne sont pas fixées exclude ,.js Les règles continuent exclude Exclure node_modules ,Voici quelques exemples：

// js Ressources
{
    
  test: /\.js$/,
  exclude: /node_modules/
  use: [
    // transpiler ...
  ]
}

// ts Ressources
{
    
  test: /\.(ts|tsx|jsx)$/,
  use: [
    // transpiler ...
  ]
}

Et ainsi de suite.,Paquet de tiers .ts Les ressources vont entrer dans transpile Champ d'application,Bien sûr., Il y a plus de détails ,Oui, par exemple. exclude Faire un jugement fonctionnel ,Dans un certain @scope/* Pas à l'intérieur. exclude .

Repositionnement

Comme ci - dessus, on ne peut pas transpile Autres sous - paquets ts La question des ressources, Maintenant, repositionnons - les , Lisez directement le code source de ces sous - paquets , Pour ne pas avoir à les construire , Qu'ils fassent vraiment partie de notre projet .

C'est comme ça.： Il faut d'abord trouver ces sous - paquets src Emplacement du code source,Et à travers alias Repositionner la référence du paquet à sa source .Comment trouver？ Le plus populaire est recommandé ici monorepo Outils d'expédition changesets En bas @manypkg/get-packages ,Voici quelques exemples：

import {
     getPackages } from '@manypkg/get-packages'
import {
     join } from 'path'

const collectAllProjectsEntryAlias = async () => {
    
  const workspaces = await getPackages(
    // ↓ Racine du projet,En général process.cwd()
    projectRootPath
  );
  return workspaces.packages.reduce(
    (obj, pkg) => {
    
      const name = pkg.packageJson?.name;
      if (name) {
    
        obj[name] = join(pkg.dir, 'src');
      }
      return obj;
    },
    {
    },
  );
}

C'est juste une simple logique ,Selon la scène, Vous devrez peut - être aussi normaliser votre sous - sac package.json Champs en, Et juger de l'existence du dossier , Et l'utilisation prévue npm La version du paquet ou la version locale, etc .

Après ça, il suffit de les mettre merge Entrez. alias C'est tout..

Regardez en arrière,Avant,Nous utilisons "main": "dist/index.js" Contenu exporté, Et maintenant nous passons par alias ：

{
    
  alias: {
    
    'some-pkg': '/path/to/some-pkg/src'
  }
}

En utilisant son code source some-pkg/src/index.ts Contenu exporté, Paire appariée ts De transpile, Pour un rafraîchissement thermique sans soudure ！

TypeScript Type Support

Sans aucun doute.,Directement à src Changement de type non reconnu ,Nous utilisons directement tsconfig.json#compilerOptions.paths Pour l'identification ,Voici quelques exemples：

{
    
  "compilerOptions": {
    
    "paths": {
    
      "some-pkg/*": ["../packages/some-pkg/*"],
    }
  }
}

Si vous voulez automatiser , On pourrait envisager de laisser le projet tsconfig.json Hérite de la génération du cadre .temp/tsconfig.base.json Pour modifier dynamiquement.

C'est fini., Notre problème de mise à jour thermique est complètement résolu , Mais est - ce vraiment si simple ？

Ensure Single Instance

Logique sous - jacente pour plusieurs instances

In monorepo Moyenne, Il est facile d'ignorer un fait important ：

• En lisant les sous - paquets , Ses dépendances sont recherchées à partir de son catalogue comme point de départ .

Cela signifie que si vous utilisez react Développer des composants réutilisables , À ce stade, selon les spécifications , Vous auriez dû laisser quelqu'un utiliser votre pack de composants react Unique, C'est - à - dire qu'on ne peut pas react Écrire dependencies ,C'est écrit. devDependencies , Parce que vous développez localement pour utiliser , Et aussi pour rappeler à la personne qui a installé votre sac , Et l'écrire peerDependencies ：

{
    
  "devDependencies": {
    
    "react": "^18.0.0"
  },
  "peerDependencies": {
    
    "react": "^18.0.0"
  }
}

Mais dans monorepo Peut être différent de npm L'utilisation du paquet ne sera installée que dependencies ,Sous - sac devDependencies Toujours dans notre coin ！ Cela conduit les composants du paquet à utiliser react Je l'ai trouvé dans son catalogue react , Et dans l'application principale react C'est différent！ Cause beaucoup hooks Problème d'écrasement de l'application .

Pour react Je répète ,C'est une erreur fatale,Peut causer un crash d'application. Un autre classique non fatal case - Oui.：Deux. antd ,Peut conduire à Message L'invite pop - up n'est pas en file d'attente .

Dans ce genre de “Plusieurs instances” Sous influence, Nous ne pouvons pas nous permettre une erreur fatale , Toutes sortes de problèmes d'expérience , Beaucoup de dépendances sont des sous - paquets avec une copie , Il y a aussi une copie de l'application principale , Le volume du produit final a été multiplié .

La solution au dilemme

À ce sujet, Je m'appelle aussi peerDependencies Situation difficile,On était pnpm monorepo Il a été discuté dans le système ：

• 《 pnpm monorepo Plusieurs exemples de composants et peerDependencies Retour en arrière du dilemme 》

Il y a deux solutions dans cet article ,L'un est par alias Alias uniformément positionné sur l'application principale pour maintenir l'instance unique ; L'autre est de les élever tous au niveau global , Pour que les deux trouvent la même instance vers le haut . Quelle que soit la solution, il n'y a pas d'extensibilité automatique , Il y a des coûts de main - d'oeuvre .

Y a - t - il une solution automatisée de glissement de fil ？

Oui., Tant que tout est dans les spécifications convenues .Ici. trade off - Oui.,Nous passons Lecture automatique Autres sous - ensembles du même entrepôt package.json De peerDependencies Champ, Et les mettre tous Essayez de localiser Allez à notre application principale .

Voici deux mots clés：

• Lecture automatique： Le principe est le même que la méthode de mise à jour de la chaleur ci - dessus ,Utiliser workspace Les outils lisent ces sous - paquets package.json Dans peerDependencies Ce qui est suffisant .

• Essayez de localiser： Certaines applications principales dépendantes doivent avoir ,Par exemple, react , Et certains sans importance 、 Dépendances non disponibles pour l'application principale , Notre application principale n'a pas besoin d'être installée du tout ,Alors c'est Essayez de localiser , Avec des sous - paquets qui ne peuvent pas être localisés , Une fois positionné, il reste unique avec l'application principale . La méthode ici devrait être requre.resolve() Ou resolve() ,Voici un exemple simple:：

  import resolve from 'resolve'
  import {
         dirname } from 'path'
  
  const alias = {
        }
  
  try {
        
    const depPkgDir = dirname(resolve.sync(
      `${
          depName}/package.json`, 
      {
         basedir: projectRootPath }
    ))
    alias[depName] = depPkgDir
  } catch {
        }
  

La nécessité de localiser les dépendances pour empêcher plusieurs instances doit être peerDependencies C'est vrai?？C'est vrai,Il doit y en avoir un., Tant que les spécifications sont élaborées .

Et ainsi de suite., Nous pouvons résoudre le problème des instances multiples .Regarde en arrière., Tant que les développeurs suivent FE Spécification de développement des limites , Peut écrire les dépendances dans peerDependencies Il est possible de charger automatiquement , Selon les spécifications de l'industrie , Ce n'est pas un Pacte , C'est une capacité fondamentale .

En plus, Pour les dépendances importantes , Peut conduire à l'application crash Le cœur de l'effondrement dépend de la position de verrouillage manuelle ,Par exemple: react Quelques dépendances du noyau ：

• react

• react-router

• react-router-dom

Bien sûr., Pour les scénarios développés à l'interne , Afin d'éviter complètement que les développeurs ne développent des sous - paquets non standard ,Non. peerDependencies , Il est possible de tenir à jour une liste de dépendances clés ,Ils sont généralement ui Bibliothèques ou dépendances possibles pour chaque projet ,Par exemple, antd / arco-design Attendez., Ensuite, repositionnez - les en permanence du côté du cadre en fonction de ces points clés .

Note:： Ne pas trop anticiper les avantages du positionnement , Ce n'est pas une dépendance centrale essayez de ne pas localiser , Le positionnement doit être maintenu dans une plage minimale , Une grande partie de leur dépendance n'entraîne souvent pas de problèmes d'expérience ou d'erreurs fatales , Mais leur version n'est pas la même dans les sous - paquets que dans l'application principale , Une fois qu'une grande version apparaît Breaking change Le gain ne vaut pas la perte .

Résumé

Nous résolvons les mises à jour thermiques et les problèmes Multi - instances importants ,Jean monorepo Le développement du projet à l'intérieur de l'entrepôt est plus fluide .

Un autre voyage , Nous n'avons pas besoin que les développeurs comprennent tout ça , Ces logiques doivent être fournies dans la boîte noire du côté du cadre , Lorsqu'il est reconnu que l'article est monorepo Auto - open in , Parce que c'est tout pour les développeurs “Bien sûr.“ .

En parlant de largeur ,monorepo Qu'est - ce qu'il y a d'autre ,Comme l'utilisation pnpm 、changesets, Qu'est - ce qu'il y a d'autre à glisser sur le côté du cadre , Comme l'auto polyfill 、 Stratégie de construction moderne optimale par défaut, etc , Comme elles ne relèvent pas du champ d'application du présent document , Laissez le lecteur explorer la recherche .

Ci - dessus.