ts monorepo
1.0.0
Tableau de contenu
L'objectif principal de ce référentiel est de faire la fonction
Go to definitionIDE sans aucune surprise, ce qui signifie qu'il fonctionnera après un nouveau clone sans avoir besoin de construire le projet.
L'objectif secondaire est de supprimer les surprises lors de la publication de packages. Le repo est configuré de sorte que chaque package obtient une sortie de construction propre sans aucun artefact provenant d'autres packages.
Tout le reste est maintenu au minimum . Outre ma configuration d'Eslint personnelle pour garder le code propre, il n'y a aucun outil supplémentaire inclus - vous êtes libre de le personnaliser selon vos propres besoins après le clonage. Les cibles de compilation, les systèmes de modules, les tremblements d'arbre, etc. vous sont laissés à décider.
Ce repo utilise PNPM, mais devrait fonctionner bien avec l'une des éléments suivants:
lerna bootstrap Je recommande fortement pnpm sur les autres solutions, non seulement parce qu'elle est généralement plus rapide, mais parce qu'elle évite les problèmes de dépendance causés par le levage (voir https://github.com/nighttrax/ts-monorepo/commit/d93139166b25fab15e9538df58a7d06270b846c9 en tant que exemple.
# Install pnpm with your preferred method: https://pnpm.io/installation.
npm i -g pnpm
# Install all dependencies.
pnpm iVoir les articles de blog suivants:
Si vous recherchez la solution de références de projet Consultez la succursale project-references .
Ce repo contient deux types d'espaces de travail:
packages : destinés à être publiés dans NPM et installés,apps : destinées à être exécutées. Un bon exemple pour illustrer la différence est create-react-app : vous ne publieriez pas une application comme celle-ci à NPM, vous l'exécuteriez, plus précisément, vous construiriez le bundle JS, puis le déploieriez quelque part.
Pour les packages, vous ne voulez pas regrouper toutes les dépendances Monorepo et les publier à la place individuellement. C'est pourquoi les packages ont une construction séparée tsconfig.json qui résout les dépendances Monorepo à node_modules .
Utilisez TSConfig-Paths pour résoudre les alias de chemin à l'exécution:
{
"scripts" : {
"start" : " ts-node -r tsconfig-paths/register src/index.ts "
}
}Voir l'exemple complet ici.
Utilisez un résolver Babel-Plugin-module pour résoudre les alias de chemin:
module . exports = {
presets : [
[ "@babel/preset-env" , { targets : { node : "current" } } ] ,
"@babel/preset-typescript" ,
] ,
plugins : [
[
"module-resolver" ,
{
alias : {
"^@nighttrax/(.+)" : "../\1/src" ,
} ,
} ,
] ,
] ,
} ;Voir l'exemple complet ici.
Utilisez tsconfig-paths-webpack-plagin pour résoudre les alias de chemin:
const TsconfigPathsPlugin = require ( "tsconfig-paths-webpack-plugin" ) ;
module . exports = {
resolve : {
plugins : [ new TsconfigPathsPlugin ( ) ]
}
} ;Voir l'exemple complet ici.
Si vous utilisez Babel , voyez cet exemple de la section Babel ci-dessus.
Si vous utilisez TS-Jest, vous pouvez utiliser son assistant pathsToModuleNameMapper :
const { pathsToModuleNameMapper } = require ( "ts-jest" ) ;
const { compilerOptions } = require ( "../../tsconfig.json" ) ;
module . exports = {
preset : "ts-jest" ,
moduleNameMapper : pathsToModuleNameMapper ( compilerOptions . paths , {
// This has to match the baseUrl defined in tsconfig.json.
prefix : "<rootDir>/../../" ,
} ) ,
} ;Voir l'exemple complet ici.
Utilisez Craco ou React-App-App pour étendre la configuration Webpack de CRA et appliquez le tsconfig-paths-webpack-plagin:
const TsconfigPathsPlugin = require ( "tsconfig-paths-webpack-plugin" ) ;
module . exports = ( config ) => {
// Remove the ModuleScopePlugin which throws when we
// try to import something outside of src/.
config . resolve . plugins . pop ( ) ;
// Resolve the path aliases.
config . resolve . plugins . push ( new TsconfigPathsPlugin ( ) ) ;
// Let Babel compile outside of src/.
const oneOfRule = config . module . rules . find ( ( rule ) => rule . oneOf ) ;
const tsRule = oneOfRule . oneOf . find ( ( rule ) =>
rule . test . toString ( ) . includes ( "ts|tsx" )
) ;
tsRule . include = undefined ;
tsRule . exclude = / node_modules / ;
return config ;
} ;Voir l'exemple complet ici. Pour les tests, consultez l'exemple de plaisanterie.
Utilisez VITE-TSCCONFIG-PATHS dans la configuration Vite:
import { defineConfig } from "vite" ;
import react from "@vitejs/plugin-react" ;
import tsconfigPaths from "vite-tsconfig-paths" ;
export default defineConfig ( {
plugins : [
react ( ) ,
tsconfigPaths ( )
] ,
} ) ;Voir l'exemple complet ici.
Étendez la configuration de la pack de Next pour permettre la compilation de packages à partir du monorepo:
module . exports = {
webpack : ( config ) => {
// Let Babel compile outside of src/.
const tsRule = config . module . rules . find (
( rule ) => rule . test && rule . test . toString ( ) . includes ( "tsx|ts" )
) ;
tsRule . include = undefined ;
tsRule . exclude = / node_modules / ;
return config ;
} ,
} ;Voir l'exemple complet ici.
Incluez les alias de chemin dans tsconfig.json et tsconfig.build.json et dire NESTJS où trouver le fichier main.js :
{
"collection" : " @nestjs/schematics " ,
"sourceRoot" : " src " ,
"entryFile" : " apps/nestjs/src/main "
}Voir l'exemple complet ici.
Étendez la configuration de WebPack du Storybook et appliquez le tsconfig-paths-webpack-plagin:
const TsconfigPathsPlugin = require ( 'tsconfig-paths-webpack-plugin' ) ;
module . exports = {
webpackFinal : async ( config ) => {
config . resolve . plugins = [
... ( config . resolve . plugins || [ ] ) ,
new TsconfigPathsPlugin ( {
extensions : config . resolve . extensions ,
} ) ,
] ;
return config ;
} ,
} ;Voir l'exemple complet ici.
