En phase avec vos analyses.
Cet héritage de MS-DOS (path de 256) limite considérablement les possibilités de Windows même 40 ans après, c’est assez dingue… un argument en faveur de travailler sur MacOS 
Bonne idée, on gagnerait beaucoup en lisibilité.
Effectivement dans les liens identifiés par le(s) parent(s), on pourrait simplifier le nom qui souvent concatène la clé fonctionnelle (enfin ce que retourne le hook getMappedExportPath ne s’en soucie pas).
- L’export de Module est un TreeView standard, dont la définition est en dur pour éviter que ce soit paramétrable, et qui n’a donc pas d’intelligence = c’est un parcours d’arbre récursif qui crée des répertoires enfants sans limite de profondeur
- Les objets du module qui n’auraient pas été coloriés pendant l’export (une définition orpheline) sont exportés simplement à la fin à la racine de la config pour n’oublier personne.
Il pourrait voir qu’un chemin dépasse 256, et ne pas exporter l’objet/la grappe dans l’arbre.
Mais je trouve que l’export ne serait plus très prédictif en fonction de la taille des (re)nommages.
On peut revoir la définition de l’arbre pour en limiter la profondeur, mais 256 c’est comme tout mettre à 1 ou 2 sous-répertoire de taille variable (les clés sont de 100 char donc ça va vite si on utilise des nommages très longs).
Et pour les liens réflexifs (items de treeview, arbre de groupes…), on finira toujours dans une impasse.
En conclusion :
A date, si on travaille sur Windows = on ne peut pas utiliser le mode éclaté JSON hiérarchique.
Uniquement le mode JSON hirérarchique en fichier unique.
Le mode éclaté déporte le problème de diff d’un modèle relationnel qu’on avait dans “1 gros fichier” dans N répertoires mal ordonnés (ex : on valide l’ajout d’un attribut alors que l’objet est supprimé ailleurs). A la base le besoin de comparer un modèle relationnel (un graph orienté de 100 types d’entité) avec un autre est un problème complexe (que les SGBD ne savent pas faire non plus au niveau DDL).
La solution de parcourir le graph sous forme hiérarchique (arbre) semble plus lisible qu’un mode “flat” comme en XML mais pas généralisable à toutes les interfaces (Windows, ZIP…).
On va devoir revenir à un export plus simple comme en XML = 1 répertoire par type d’objets dans le mode éclaté JSON + N fichiers JSON / 1 par record.
On peut éventuellement garder une vision hiérarchique avec un fichier JSON informatif à la racine qui suit la définition du TreeView mais avec uniquement les champs clés. Mais cela va induire des redondances donc déphasage potentiel d’information si on modifie les fichiers sans passer par Simplicité.
Mon avis :
- Si le CI est automatique, que ce soit en arbre ou non ne change rien.
- Pour contre si on veut passer par une étape de merge humain (validation des livrables avant intégration), la UI sert déjà à montrer les modules en arbre au niveau du diff + sert à fabriquer et appliquer le delta par patch dans le master (push de certaines modifs) ou en local (pull).
Qu’en pensez-vous ?
Il va falloir faire un choix.