Maison  >  Article  >  interface Web  >  Rationalisation de l'organisation des fichiers dans les projets JS : automatisation de l'imbrication des fichiers avec Bash

Rationalisation de l'organisation des fichiers dans les projets JS : automatisation de l'imbrication des fichiers avec Bash

Patricia Arquette
Patricia Arquetteoriginal
2024-10-14 06:24:03964parcourir

Streamlining File Organisation in JS Projects: Automating file Nesting with Bash

Dans un projet JS, vous commencez souvent avec un seul fichier pour un composant, ou quoi que ce soit d'ailleurs.

À un moment donné, vous constaterez peut-être que vous avez besoin de fichiers supplémentaires, pour des tests, etc.

par ex.

  • mon-composant.tsx
  • mon-composant.spec.ts
  • mon-composant.module.css
  • mon-composant.stories.tsx

J'évite ça,
Je pense qu'il est beaucoup plus ordonné de placer tous les fichiers associés dans un dossier et d'utiliser la convention de dénomination des fichiers d'index.

Donc, dès que j'ai besoin d'un deuxième fichier, je déplacerais généralement my-component.tsx dans as
dossier mon-component/index.tsx

fichiers index.js

Pour les modules CommonJS et esm, ces deux fichiers sont équivalents

  • mon-service.ts
  • mon-service/index.ts

Une fonctionnalité intéressante de ceci est que l'import: import { Foo } from "./my-service" fonctionnera à la fois avec les fichiers my-service.ts et my-service/index.ts, sans nécessiter aucune modification. le chemin d'importation

Le Problème Ennuyé

Je trouve ça un peu fastidieux de faire la danse de...

$ mkdir -p components/my-service
$ git mv components/my-component.tsx components/my-component/index.tsx

Et si je me souviens mal si le fichier n'est pas encore sous contrôle de version, je pourrais obtenir un

fatal: not under version control, source=components/my-component.tsx,
 destination=components/my-component/index.tsx

-plus de gêne..

Ou peut-être plus ennuyeux, si je me trompe dans l'autre sens et que j'utilise mv, je pourrais me retrouver avec un statut git de

Changes not staged for commit:
        deleted:    components/my-component.tsx

Untracked files:
        components/my-component/

Comme la commande mv par défaut est traitée comme une suppression et une création d'un nouveau fichier par git

Ma solution

J'ai écrit un script bash pour automatiser la danse

Exemple

$ ./nest.sh components/my-component.tsx

résultats en

$ tree components
components
└── my-component
    └── index.tsx

Si le fichier est sous contrôle de version, le script utilise git mv sinon utilise le vieux mv

Exemple 2

plusieurs fichiers...

$ ./nest.sh components/my-component.tsx
$ ./nest.sh components/my-component.spec.ts
$ ./nest.sh components/my-component.css

résultats en

$ tree components
components
└── my-component
    └── index.tsx
    └── index.spec.ts
    └── index.css

Voir le script bash dans un Github Gist ici

J'ai le script nommé nest qui se trouve dans un dossier bin dans mon $PATH afin que je puisse l'utiliser comme commande n'importe où

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn