Bonjour, je m'appelle Dmitry Karlovsky et j'adore MAM. M AM gouverne les modules Gnostic M , me faisant ainsi gagner la part du lion de la routine.

Un module agnostique , contrairement au module traditionnel, n'est pas un fichier avec une source, mais un répertoire dans lequel il peut y avoir des sources dans différents langages: logique de programme en JS / TS , tests pour celui-ci en TS / JS , composition des composants dans view.tree , styles en CSS , localisation en locale=*.json , images, etc., etc. Si vous le souhaitez, il n’est pas difficile d’obtenir le support d’une autre langue. Par exemple, Stylus pour écrire des styles ou HTML pour décrire des modèles.

Les dépendances entre les modules sont suivies automatiquement en analysant la source. Si le module est activé, il est activé dans son ensemble - chaque code source du module est transposé et tombe dans le bundle correspondant: scripts - séparément, styles - séparément, tests - séparément. Pour différentes plates-formes - leurs bundles: pour un nœud - le leur, pour un navigateur - le leur.

Automatisation complète, manque de configuration et de passe-partout, tailles de paquet minimales, pompage automatique des dépendances, développement de centaines de bibliothèques et d'applications aliénées dans une base de code sans douleur ni souffrance. Wow quelle dépendance! Retirez les enceintes, les enfants nerveux des moniteurs et bienvenue dans le sous-marin!

La philosophie

MAM est une expérience audacieuse pour changer radicalement la façon dont le code est organisé et le processus de travail avec lui. Voici les principes de base:

Conventions au lieu de la configuration. Des accords raisonnables, simples et universels vous permettent d'automatiser l'ensemble de la routine, tout en conservant la commodité et l'uniformité entre les différents projets.

L'infrastructure est séparée, le code est séparé. Une situation n'est pas rare lorsque vous devez développer des dizaines, voire des centaines de bibliothèques et d'applications. Ne déployez pas l'infrastructure d'assemblage, de développement, de déploiement, etc. pour chacun d'eux. Il suffit de le poser une fois puis de riveter des applications comme des tartes.

Ne payez pas pour ce que vous n'utilisez pas. Vous utilisez une sorte de module - il est inclus dans le bundle avec toutes ses dépendances. Ne pas utiliser - ne s'allume pas. Plus les modules sont petits, plus la granularité est grande et moins de code inutile dans le bundle.

Code redondant minimum. Décomposer le code en modules devrait être aussi simple que d'écrire tout le code dans un seul fichier. Sinon, le développeur sera paresseux pour diviser les gros modules en petits modules.

Aucun conflit de version. Il n'y a qu'une seule version - la version actuelle. Il n'est pas nécessaire de dépenser des ressources pour prendre en charge les anciennes versions, si vous pouvez les dépenser pour mettre à jour ces dernières.

Gardez un doigt sur le pouls. La rétroaction la plus rapide concernant les incompatibilités ne permettra pas au code de mal tourner.

Le moyen le plus simple est le plus sûr. Si le bon chemin nécessite des efforts supplémentaires, assurez-vous que personne ne s'y rendra.

Importations / exportations

Nous ouvrons le premier projet qui a vu le jour en utilisant un système de modules moderne: Un module a moins de 300 lignes de long, dont 30 sont des importations.

Mais ce sont encore des fleurs: pour une fonction de 9 lignes, 8 importations sont nécessaires.

Et mon préféré: pas une seule ligne de code utile. 20 lignes de valeurs de décalage du tas de modules en un, afin que vous puissiez plus tard importer à partir d'un module, et non de vingt.

Tout cela est un passe-partout, ce qui conduit au fait que les développeurs sont trop paresseux pour allouer de petits morceaux de code dans des modules séparés, préférant les gros modules aux petits. Et même s'ils ne sont pas paresseux, il s'avère que beaucoup de code pour importer de petits modules, ou des modules spéciaux qui importent beaucoup de modules en eux-mêmes et les exportent tous en vrac.

Tout cela conduit à une faible granularité du code et à un gonflement de la taille des bundles avec du code inutilisé, ce qui a la chance d'être proche de celui qui est utilisé. Pour JS, ils essaient de résoudre ce problème en compliquant le pipeline d'assemblage en ajoutant ce que l'on appelle le «tremblement d'arbre», ce qui coupe l'excédent de ce que vous avez importé. Cela ralentit l'assemblage, mais tout n'est pas coupé.

Idée: que se passe-t-il si nous n'importons pas, mais prenons et utilisons simplement, et le collectionneur lui-même trouvera ce qui doit être importé?

Les IDE modernes peuvent générer automatiquement des importations pour les entités que vous utilisez. Si l'EDI peut le faire, qu'est-ce qui empêche le collecteur de le faire? Il suffit d'avoir une convention simple sur la dénomination et l'emplacement des fichiers, ce qui serait pratique pour l'utilisateur et compréhensible pour la machine. PHP a depuis longtemps une telle convention standard: PSR-4 . MAM introduit la même chose pour les fichiers .ts et .jam.js: les noms commençant par $ sont le nom complet d' une entité globale dont le code est chargé le long du chemin obtenu à partir de FQN en remplaçant les délimiteurs par des barres obliques. Un exemple simple de deux modules:

mon / alert / alert.ts

 const $my_alert = alert // FQN    

mon / app / app.ts

 $my_alert( 'Hello!' ) // ,   /my/alert/ 

Un module entier à partir d'une seule ligne - quoi de plus simple? Le résultat ne tarde pas à venir: la simplicité de création et d'utilisation des modules permet de minimiser leur taille. En conséquence, pour maximiser la granularité. Et comme une cerise - minimiser la taille des faisceaux sans secouer les arbres.

Un bon exemple est la famille de modules de validation JSON / mol / data . Si vous utilisez la fonction $mol_data_integer quelque part dans votre code, les modules /mol/data/integer et /mol/data/number , dont dépend $mol_data_integer , seront inclus dans le bundle. Mais, par exemple, le collecteur /mol/data/email ne lira même pas à partir du disque, car personne n'en dépend.

Ratisser un gâchis

Depuis que nous avons commencé à frapper Angular, nous ne nous arrêterons pas. Où pensez-vous rechercher la applyStyles fonction applyStyles ? Vous ne devinerez pas sur /packages/core/src/render3/styling_next/bindings.ts . La possibilité de placer n'importe quoi n'importe où conduit au fait que, dans chaque projet, nous observons un système de localisation de fichiers unique, qui ne se prête souvent à aucune logique. Et si l'IDE est souvent sauvegardé par le «saut à la définition», alors afficher le code sur le github ou revoir la demande de pull est privé de cette opportunité.

Idée: que se passe-t-il si les noms d'entité correspondent strictement à leur emplacement?

Pour placer le code dans le fichier /angular/packages/core/src/render3/stylingNext/bindings.ts , dans l'architecture MAM, vous devez nommer l'entité $angular_packages_core_src_render3_stylingNext_applyStyles , mais bien sûr, personne $angular_packages_core_src_render3_stylingNext_applyStyles , car il y a tellement plus dans le nom. Mais les noms dans le code que je veux voir courts et concis, donc le développeur essaiera d'exclure tous les inutiles du nom, ne laissant que l'important: $angular_render3_applyStyles . Et il sera situé en conséquence dans /angular/render3/applyStyles/applyStyles.ts .

Remarquez comment MAM utilise les faiblesses des développeurs pour atteindre le résultat souhaité: chaque entité obtient un nom court globalement unique qui peut être utilisé dans n'importe quel contexte. Par exemple, dans les messages de commits, ces noms vous permettent de saisir rapidement et précisément ce dont ils parlent:

 73ebc45e517ffcc3dcce53f5b39b6d06fc95cae1 $mol_vector: range expanding support 3a843b2cb77be19688324eeb72bd090d350a6cc3 $mol_data: allowed transformations 24576f087133a18e0c9f31e0d61052265fd8a31a $mol_data_record: support recursion 

Ou, disons que vous voulez trouver toutes les mentions du module $ mol_fiber sur Internet - ce qui rend plus facile que jamais grâce à FQN.

Dépendances cycliques

Écrivons 7 lignes de code simple dans un seul fichier:

 export class Foo { get bar() { return new Bar(); } } export class Bar extends Foo {} console.log(new Foo().bar); 

Malgré la dépendance cyclique, cela fonctionne correctement. Nous le décomposons en 3 fichiers:

mon / foo.js

 import { Bar } from './bar.js'; export class Foo { get bar() { return new Bar(); } } 

mon / bar.js

 import { Foo } from './foo.js'; export class Bar extends Foo {} 

mon / app.js

 import { Foo } from './foo.js'; console.log(new Foo().bar); 

Oups, ReferenceError: Cannot access 'Foo' before initialization . Quel genre de non-sens? Pour résoudre ce problème, notre app.js doit savoir que foo.js dépend de bar.js Par conséquent, nous devons d'abord importer bar.js , qui importe foo.js Après quoi, nous pouvons déjà importer foo.js sans erreur:

mon / app.js

 import './bar.js'; import { Foo } from './foo.js'; console.log(new Foo().bar); 

Ces navigateurs, ce NodeJS, ce Webpack, ce Parcel - ils fonctionnent tous de façon tordue avec des dépendances circulaires. Et bien, ils les interdiraient simplement - on pourrait immédiatement compliquer le code pour qu'il n'y ait pas de boucles. Mais ils peuvent bien fonctionner, puis bam, et donner une erreur incompréhensible.

Idée: que se passe-t-il si lors de l'assemblage, nous collons simplement les fichiers dans le bon ordre, comme si tout le code était à l'origine écrit dans un seul fichier?

Divisons le code en utilisant les principes de MAM:

mon / foo / foo.ts

 class $my_foo { get bar() { return new $my_bar(); } } 

mon / bar / bar.ts

 class $my_bar extends $my_foo {} 

mon / app / app.ts

 console.log(new $my_foo().bar); 

Tout de même 7 lignes de code qui étaient à l'origine. Et ils fonctionnent simplement sans chamanisme supplémentaire. Le fait est que le collecteur comprend que la dépendance de my/bar sur my/foo plus stricte que my/foo sur my/bar . Cela signifie que vous devez inclure ces modules dans le bundle dans cet ordre: my/foo , my/bar , my/app .

Comment le collectionneur comprend-il cela? Maintenant, l'heuristique est simple - par le nombre d'indentation dans la ligne dans laquelle la dépendance est détectée. Veuillez noter qu'une dépendance plus forte dans notre exemple a une indentation nulle et une faible a une indentation double.

Différentes langues

Il se trouve que pour différentes choses, nous avons des langues différentes pour ces différentes choses aiguisées. Les plus courants sont: JS, TS, CSS, HTML, SVG, SCSS, Less, Stylus. Chacun a son propre système de modules, qui n'interagit en aucune façon avec les autres langues. Il va sans dire, environ 100500 types de langues plus spécifiques. Par conséquent, pour connecter un composant, vous devez connecter séparément ses scripts, séparer les styles, enregistrer les modèles séparément, configurer séparément le déploiement des fichiers statiques dont il a besoin, etc., etc.

Grâce aux chargeurs, Webpack essaie de résoudre ce problème. Mais il a un point d'entrée, c'est un script qui connecte déjà des fichiers dans d'autres langues. Et si nous n'avons pas besoin d'un script? Par exemple, nous avons un module avec de beaux styles pour les assiettes et nous voulons qu'ils aient les mêmes couleurs dans le thème clair et d'autres dans le noir:

 .dark-theme table { background: black; } .light-theme table { background: white; } 

De plus, si nous dépendons du sujet, alors un script devrait être chargé qui installera le sujet souhaité en fonction de l'heure de la journée. Autrement dit, CSS dépend en fait de JS.

Idée: et si un système modulaire ne dépend pas des langues?

Étant donné que dans MAM, le système modulaire est séparé des langues, les dépendances peuvent être inter-langues. CSS peut dépendre de JS, qui peut dépendre de TS, qui peut dépendre d'un autre JS. Cela est dû au fait que les dépendances de source sont détectées sur les modules et que les modules sont entièrement connectés et peuvent contenir des codes source dans toutes les langues. Dans le cas de l'exemple de thèmes, cela ressemble à ceci:

/my/table/table.css

 /* ,   /my/theme */ [my_theme="dark"] table { background: black; } [my_theme="light"] table { background: white; } 

/my/theme/theme.js

 document.documentElement.setAttribute( 'my_theme' , ( new Date().getHours() + 15 ) % 24 < 12 ? 'light' : 'dark' , ) 

En utilisant cette technique, vous pouvez d'ailleurs implémenter votre Modernizr , mais sans 300 contrôles dont vous n'avez pas besoin, car seuls les contrôles dont votre CSS dépend vraiment seront inclus dans le bundle.

De nombreuses bibliothèques

En règle générale, le point d'entrée pour la création d'un bundle est une sorte de fichier. Dans le cas de Webpack, il s'agit de JS. Si vous développez de nombreuses bibliothèques et applications aliénables, vous avez besoin de beaucoup de bundles. Et pour chaque bundle, vous devez créer un point d'entrée distinct. Dans le cas de Parcel, le point d'entrée est HTML, qui pour les applications devra de toute façon être créé. Mais pour les bibliothèques, ce n'est pas très approprié.

Idée: que se passe-t-il si un module peut être assemblé en un bundle indépendant sans préparation préalable?

Préparons la dernière version du générateur de projet MAM $ mol_build:

 mam mol/build 

Maintenant, lancez ce collecteur et laissez-le se reconstituer pour vous assurer qu'il est toujours en mesure de se rassembler:

 node mol/build/-/node.js mol/build 

Bien que non, demandons-lui d'exécuter des tests avec l'assembly:

 node mol/build/-/node.test.js mol/build 

Et si tout s'est bien passé, publiez le résultat dans NPM:

 npm publish mol/build/- 

Comme vous pouvez le voir, lors de l'assemblage du module, un sous-répertoire est créé avec le nom - et tous les artefacts d'assemblage y sont placés. Passons en revue les fichiers que vous pouvez y trouver:

• web.dep.json - toutes les informations sur le graphe de dépendances
• web.js - ensemble de scripts de navigateur
• web.js.map - sorsmaps pour lui
• web.esm.js - il se présente sous la forme d'un module es
• web.esm.js.map - et sorsmaps pour cela
• web.test.js - bundle de test
• web.test.js.map - et pour les tests sorsmap
• web.d.ts - bundle avec les types de tout ce qui est dans le bundle de script
• web.css - bundle avec styles
• web.css.map - et sortsmaps pour cela
• web.test.html - point d'entrée pour exécuter des tests de performances dans un navigateur
• web.view.tree - déclarations de tous les composants inclus dans le bundle view.tree
• web.locale=*.json - bundles avec textes localisés, chaque bundle a son propre bundle
• package.json - vous permet de publier immédiatement le module assemblé dans NPM
• node.dep.json - toutes les informations sur le graphe de dépendances
• node.js - bundle de script de noeud
• node.js.map - sorsmaps pour cela
• node.esm.js - il se présente sous la forme d'un es-module
• node.esm.js.map - et sorsmaps pour cela
• node.test.js - le même bundle, mais aussi avec des tests
• node.test.js.map - et sorsmaps pour cela
• node.d.ts - bundle avec les types de tout ce qui est dans le bundle de script
• node.view.tree - déclarations de tous les composants inclus dans le bundle view.tree
• node.locale=*.json - bundles avec des textes localisés, chaque bundle a son propre bundle

La statique est simplement copiée avec les chemins. Par exemple, prenez une application qui affiche ses propres codes source . Ses sources sont ici:

• /mol/app/quine/quine.view.tree
• /mol/app/quine/quine.view.ts
• /mol/app/quine/index.html
• /mol/app/quine/quine.locale=ru.json

Malheureusement, dans le cas général, le collecteur ne peut pas savoir que nous aurons besoin de ces fichiers lors de l'exécution. Mais nous pouvons le lui dire en mettant un fichier spécial à proximité:

/mol/app/quine/quine.meta.tree

 deploy \/mol/app/quine/quine.view.tree deploy \/mol/app/quine/quine.view.ts deploy \/mol/app/quine/index.html deploy \/mol/app/quine/quine.locale=ru.json 

À la suite de l'assembly /mol/app/quine , ils seront copiés de la manière suivante:

• /mol/app/quine/-/mol/app/quine/quine.view.tree
• /mol/app/quine/-/mol/app/quine/quine.view.ts
• /mol/app/quine/-/mol/app/quine/index.html
• /mol/app/quine/-/mol/app/quine/quine.locale=ru.json

Maintenant, le répertoire /mol/app/quine/- peut être disposé sur n'importe quel hébergement statique et l'application sera entièrement fonctionnelle.

Plateformes cibles

JS peut être exécuté à la fois sur le client et sur le serveur. Et comme c'est cool quand on peut écrire un code et ça marchera partout. Cependant, parfois l'implémentation de la même chose sur le client et le serveur est fondamentalement différente. Et je veux, par exemple, une implémentation à utiliser pour un nœud, et une autre pour un navigateur.

Idée: que se passe-t-il si le but du fichier est reflété dans son nom?

MAM utilise un système de balises dans les noms de fichiers. Par exemple, le module $mol_state_arg permet d'accéder aux paramètres d'application définis par l'utilisateur. Dans le navigateur, ces paramètres sont définis via la barre d'adresse. Et dans le nœud, via des arguments de ligne de commande. $mol_sate_arg résume le reste de l'application de ces nuances en implémentant les deux options avec une seule interface, en les plaçant dans des fichiers:

• / mol / state / arg / arg. web .ts - implémentation pour les navigateurs
• / mol / state / arg / arg. node .ts - implémentation pour un noeud

Les sources non balisées avec ces balises sont incluses quelle que soit la plateforme cible.

Une situation similaire est observée avec les tests - ils veulent être stockés à côté du reste des sources, mais ils ne veulent pas être inclus dans le bundle qui va à l'utilisateur final. Par conséquent, les tests sont également marqués avec une balise distincte:

• / mol / state / arg / arg. test .ts - tests de module, ils tomberont dans le bundle de test

Les balises peuvent être paramétriques. Par exemple, avec chaque module, des textes dans différentes langues peuvent venir et doivent être inclus dans les packs de langues correspondants. Un fichier texte est un dictionnaire JSON standard nommé avec les paramètres régionaux dans le nom:

• / mol / app / life / life. locale = ru .json - textes pour la langue russe
• / mol / app / life / life. locale = jp .json - textes pour le japonais

Enfin, que se passe-t-il si nous voulons placer des fichiers à proximité, mais que le collecteur les ignore et ne les inclut pas automatiquement dans le bundle? Il suffit d'ajouter au début de leur nom tout caractère non alphanumérique. Par exemple:

• / hyoo / jouets / . git - commence par un point, donc le collecteur ignorera ce répertoire

Versioning

Google a d'abord publié AngularJS et l'a publié dans NPM en tant angular . Puis il a créé un tout nouveau framework avec un nom similaire - Angular et l'a publié sous le même nom, mais déjà la version 2. Maintenant, ces deux feux d'artifice se développent indépendamment. Un seul changement de rupture d'API se produit entre les versions principales. Et l'autre - entre le mineur . Et comme il est impossible de mettre deux versions de la même dépendance au même niveau, il ne peut être question de transition en douceur, lorsque deux versions de la bibliothèque coexistent simultanément pendant un certain temps dans l'application.

Il semble que l'équipe d'Angular ait déjà marché sur tous les râteaux possibles. Et encore une chose: le code cadre est divisé en plusieurs grands modules. Au début, ils les ont versionnés indépendamment, mais très rapidement, même eux-mêmes ont commencé à se demander quelles versions des modules sont compatibles entre elles, sans parler des développeurs ordinaires. Par conséquent, Angular est passé au versionnage de bout en bout , où la version principale du module peut changer même sans aucune modification du code. La prise en charge de plusieurs versions de plusieurs modules est un gros problème à la fois pour les responsables eux-mêmes et pour l'écosystème dans son ensemble. Après tout, beaucoup de ressources de tous les membres de la communauté sont consacrées à assurer la compatibilité avec des modules déjà obsolètes.

La belle idée de la version sémantique se transforme en une dure réalité - vous ne savez jamais si quelque chose se cassera lorsque vous changez la version mineure ou même la version du patch . Par conséquent, dans de nombreux projets, une version spécifique de la dépendance est corrigée. Cependant, un tel correctif n'affecte pas les dépendances transitives, qui peuvent être tirées vers la dernière version lors de l'installation à partir de zéro, mais peuvent rester les mêmes si elles sont déjà installées. Ce gâchis conduit au fait que vous ne pouvez jamais compter sur une version fixe et que vous devez vérifier régulièrement la compatibilité avec les versions actuelles des dépendances (au moins transitives).

Mais qu'en est-il des fichiers de verrouillage ? Si vous développez une bibliothèque qui est installée via des dépendances, le fichier de verrouillage ne vous aidera pas, car il sera ignoré par le gestionnaire de packages. Pour l'application finale, le fichier de verrouillage vous donnera la soi-disant «reproductibilité des assemblages». Mais soyons honnêtes. Combien de fois avez-vous besoin de créer l'application finale à partir de la même source? Exactement une fois. Recevoir la sortie, indépendamment de tout NPM, l'artefact d'assemblage: un binaire exécutable, un conteneur de docker ou juste une archive avec tout le code nécessaire pour l'exécuter. J'espère que vous ne faites pas d' npm install sur prod?

Certains trouvent l'utilisation de fichiers de verrouillage dans la mesure où le serveur CI compile exactement ce que le développeur a commis. Mais attendez, le développeur lui-même peut simplement l'assembler sur sa machine locale. , , , . Continuous Integration , , , , - . CI , .

, , . , Angular@4 ( 3). , , " " " ". Angular@4 , Angular@5. Angular@6, . Angular TypeScript . . , 2 , … , business value , , , , .

, , , , 2 . : , — , — . 3 React, 5 jQuery, 7 lodash.

: — ?

. - . , . , . , . , . , . , , . : issue, , workaround, pull request, , . , , . . .

, . , , . . . : , , -. - — . , , - . , , , NPM . , . .

, ? — . mobx , mobx2 API . — , : , . mobx mobx2 , API. API, .

. — . , :

 var pages_count = $mol_atom2_sync( ()=> $lib_pdfjs.getDocument( uri ).promise ).document().numPages 

mol_atom2_sync lib_pdfjs , :

 npm install mol_atom2_sync@2.1 lib_pdfjs@5.6 

, , — , . ? — , *.meta.tree , :

/.meta.tree

 pack node git \https://github.com/nin-jin/pms-node.git pack mol git \https://github.com/eigenmethod/mol.git pack lib git \https://github.com/eigenmethod/mam-lib.git 

. .

NPM

MAM — NPM . , — . , , NPM .

NPM , $node. , - -:

/my/app/app.ts

 $node.portastic.find({ min : 8080 , max : 8100 , retrieve : 1 }).then( ( ports : number[] ) => { $node.express().listen( ports[0] ) }) 

, . - lib NPM . , NPM- pdfjs-dist :

/lib/pdfjs/pdfjs.ts

 namespace $ { export let $lib_pdfjs : typeof import( 'pdfjs-dist' ) = require( 'pdfjs-dist/build/pdf.min.js' ) $lib_pdfjs.disableRange = true $lib_pdfjs.GlobalWorkerOptions.workerSrc = '-/node_modules/pdfjs-dist/build/pdf.worker.min.js' } 

/lib/pdfjs/pdfjs.meta.tree

 deploy \/node_modules/pdfjs-dist/build/pdf.worker.min.js 

, .

. create-react-app angular-cli , . , , eject . . , , .

: ?

MAM . .

MAM MAM , :

 git clone https://github.com/eigenmethod/mam.git ./mam && cd mam npm install npm start 

8080 . , — MAM.

( — acme ) ( — hello home ):

/acme/acme.meta.tree

 pack hello git \https://github.com/acme/hello.git pack home git \https://github.com/acme/home.git 

npm start :

 npm start acme/hello acme/home 

. — . , , . — : https://t.me/mam_mol