feat(look and feel): create look and feel packages #227

PeioDeLaVega · 2024-03-26T13:16:27Z

No description provided.

pplancq · 2024-03-27T08:18:15Z

Je ne comprend pas l'intérêt de cette PR, peut tu donné plus d'explication sur le pourquoi qu'il faudrait sépare les packages ?

PeioDeLaVega · 2024-03-27T16:19:42Z

Je ne comprend pas l'intérêt de cette PR, peut tu donné plus d'explication sur le pourquoi qu'il faudrait sépare les packages ?

Il a été acté en Instance de Design System le 20/02 que le socle technique des Design Systems serait comme suit :

1 repo unique aux 2 DS pour faciliter la convergence lorsque toutes les verticales auront convergé
2 implémentations distinctes : séparation par dossier dans les sources du repo (1 Slash / 1 L&F)
1 référentiel Design unique dédiée aux DS : Zeroheight (alimenté via Figma)

pplancq · 2024-03-28T13:31:20Z

Je ne comprend pas l'intérêt de cette PR, peut tu donné plus d'explication sur le pourquoi qu'il faudrait sépare les packages ?

Il a été acté en Instance de Design System le 20/02 que le socle technique des Design Systems serait comme suit :

1 repo unique aux 2 DS pour faciliter la convergence lorsque toutes les verticales auront convergé

2 implémentations distinctes : séparation par dossier dans les sources du repo (1 Slash / 1 L&F)

1 référentiel Design unique dédiée aux DS : Zeroheight (alimenté via Figma)

Et bien justement c'est ce que l'on fait ici sur ce repo, un repo unique pour les 2 DS.
@JLou , @samuel-gomez vous confirmez ?

samuel-gomez · 2024-03-28T13:54:47Z

@pplancq je comprends ton questionnement, il y a eu pas mal de débats, je n'étais pas en phase avec cela mais c'est effectivement ce qui a été acté sous condition que la PR soit faite par ceux qui souhaitaient mettre cela en place.
La gestion des versions ne sera pas non plus la même (Slash en SemVer et L&F en CalVer) même si je pense que notre structure actuelle pourrait également répondre à ce besoin.

samuel-gomez · 2024-03-28T14:00:03Z

par contre @PeioDeLaVega des développements ont déjà été effectués sur la partie L&F mais je ne vois pas ces composants basculés dans le nouveau dossier, il était convenu de ne pas perdre le travail accompli 😉

PeioDeLaVega · 2024-03-28T14:16:04Z

@samuel-gomez Merci pour ton retour. Effectivement, je n'ai pas encore migré le travail déjà accompli, je préfère y aller par itération. Si le contenu de ma PR vous satisfait, je lancerai le processus de migration du travail déjà accompli dans un second temps sous le contrôle de la gouvernance Look&Feel.

pplancq · 2024-03-29T08:03:11Z

@pplancq je comprends ton questionnement, il y a eu pas mal de débats, je n'étais pas en phase avec cela mais c'est effectivement ce qui a été acté sous condition que la PR soit faite par ceux qui souhaitaient mettre cela en place. La gestion des versions ne sera pas non plus la même (Slash en SemVer et L&F en CalVer) même si je pense que notre structure actuelle pourrait également répondre à ce besoin.

Oki je comprend.

pplancq

Je pense qu'il aurait mieux valu déplacer au lieu de créer.

De plus le workflow de publish principale dans pas été update et donc par conséquence il va publish tous les packages sans distinction

pplancq · 2024-03-29T08:11:32Z

package.json

+    "packages/look-and-feel/css",
+    "packages/look-and-feel/react",


pourquoi créer un sous-sous package ?

N'aurait-il pas été plus simple de renommer les package css et react en css-agent et react-agent et de créer deux nouveaux package css-client et react-client.

De plus avec ce nommage il nous serait possible de créer des packages css-base et/ou react-base pour des asset commun au 2 design-system

Hello,

Merci pour ton review ! Peut-être que j'ai mal compris mais si la structure que tu proposes est la suivante :

/ |-- packages/ |-- css-agent/ |-- css-client/ |-- react-agent/ |-- react-client/

alors oui cela aurait été plus simple de renommer les packages mais on ne matérialiserait pas la séparation entre Slash et Look and Feel avec cette structuration applanie.

De plus -agent et -client ne reflètent pas explicitement slash et look-and-feel et cela pourrait induire en erreur ceux qui arrivent sur le repo et qui ne connaissent pas nos design systems, qui pourraient penser que nous n'en avons qu'un, décliné en populations cibles, ce qui n'est pas le cas : nous en avons bien 2 (au moins). Pour moi cette notion de "population cible" (agent/client) pourrait être traduite dans le readme de chaque design system si nécessaire.

Je suis donc d'avis à garder 2 répertoires distincts et clairement nommés du nom de chaque DS, conformément à ce qui a été décidé.

Par contre @PeioDeLaVega il n'est pas nécessaire ici de nommer chaque sous répertoire, tu peux faire

+ "packages/look-and-feel/*"

Pour la structure oui c'est bien ça dont je parlait

/ |-- packages/ |-- css-agent/ |-- css-client/ |-- react-agent/ |-- react-client/

Personnellement je trouve cette structure plus simples et la séparation est bien visible mais ce n'est que mon avis 😉

Après pour le nommage depuis le début on est parti sur agent pour désigner slash et client pour look-and-feel

Cela risque de faire beaucoup de changement pour les contributeurs.

à la limite ce que l'on peux faire c'est

/ |-- packages/ |-- look-and-feel-css/ |-- look-and-feel-react/ |-- slash-css/ |-- slash-react/

on reste sur une structure à plat des dossiers mais comme le nom du design-system et en préfix cela permet une meilleur visibilité.

Après pour le nommage depuis le début on est parti sur agent pour désigner slash et client pour look-and-feel

Cela risque de faire beaucoup de changement pour les contributeurs.

Yes ça fait beaucoup de changements j'en suis consient, en même temps je trouve normal de faire des ajustements en début de projet. Le risque serait de lier l'avenir du projet à des positions initiales qu'on se refuse de revoir.

En l'occurrence "agent" ou "client" n'ont pas plus de sens que "B2B" ou "B2C" par exemple, le fait est qu'ils s'appellent "Slash" et "Look and Feel" : les obfusquer par "agent", "client" (ou même "B2B" et "B2C" pour reprendre mon exemple) ne servirait qu'à induire la personne qui n'a pas le contexte à penser que nous n'avons qu'un design system !

à la limite ce que l'on peux faire c'est

/
|-- packages/
|-- look-and-feel-css/
|-- look-and-feel-react/
|-- slash-css/
|-- slash-react/

on reste sur une structure à plat des dossiers mais comme le nom du design-system et en préfix cela permet une meilleur visibilité.

Cela faisait sens de grouper les packages css et react au sein d'un répertoire look-and-feel dès lors que ces packages ont un workflow et cycle de vie qu'ils ne partagent pas avec les packages de Slash. Mais on peut adopter cette structure si tu y tiens.

C'est juste une question de préférence après on peut remonter d'une arbo package n'as pas vraiment de sens on pour pourrais faire comme ceci

/ |-- look-and-feel/ |-- css/ |-- react/ |-- slash/ |-- css/ |-- react/

comme cela on a la séparation franche, sa coller avec le sample

après je suis d'accord avec le reste.

/ |-- look-and-feel/ |-- css/ |-- react/ |-- slash/ |-- css/ |-- react/

Plus simple et le plus clair effectivement, go pour moi.

@PeioDeLaVega Je vois que tu as ramener sur

/ |-- packages/ |-- look-and-feel-css/ |-- look-and-feel-react/

Moi cela me va, comme dit plus haut j'aime pas trop qu'il y en trop d'arborescence pour les différents packages.

Par contre tu n'a fait que de l'ajout sans aucune modification des

/ |-- packages/ |-- css/ |-- react/

est une volonté pour permettre des test les workflow ou ne vaudrait il pas mieux tous séparer d'un coup ?

packages/look-and-feel/config/eslint.config.js

packages/look-and-feel/css/.eslintrc.js

packages/look-and-feel/css/.prettierignore

pplancq · 2024-05-15T08:52:23Z

.github/workflows/publish.yml

il faudrait changer les steps:

- run: npm version "${{ steps.gitversion.outputs.fullSemVer }}" --workspaces --workspaces-update=true - run: npm publish --workspace "packages" --access public

par

- run: npm version "${{ steps.gitversion.outputs.fullSemVer }}" -w packages/css -w packages/react - run: npm publish -w packages/css -w packages/react --access public

pplancq · 2024-05-15T08:52:51Z

.github/workflows/publish-look-and-feel.yml

+      - run: npm version ${{ steps.determine_version.outputs.version }} -w packages/look-and-feel/css -w packages/look-and-feel/react
+      - run: npm publish -w packages/look-and-feel/css -w packages/look-and-feel/react --access public


Suggested change

- run: npm version ${{ steps.determine_version.outputs.version }} -w packages/look-and-feel/css -w packages/look-and-feel/react

- run: npm publish -w packages/look-and-feel/css -w packages/look-and-feel/react --access public

- run: npm version ${{ steps.determine_version.outputs.version }} -w packages/look-and-feel-css -w packages/look-and-feel-react

- run: npm publish -w packages/look-and-feel-css -w packages/look-and-feel-react --access public

pplancq · 2024-05-15T08:55:13Z

.github/workflows/publish-look-and-feel.yml

+          echo '::set-output name=version::$VERSION'
+      - run: npm run package:check
+      - run: npm ci
+      - run: npm run build


Suggested change

- run: npm run build

- run: npm run build:look-and-feel

johnmeunier

Pour la prochaine PR, n'hésite pas à fournir une description détaillé surtout pour ce genre de cas

jmraxa · 2024-09-12T14:16:06Z

Découpé en #466 et #438

pplancq assigned PeioDeLaVega Mar 27, 2024

pplancq added the look'n feel label Mar 27, 2024

pplancq requested changes Mar 29, 2024

View reviewed changes

pplancq reviewed May 15, 2024

View reviewed changes

PeioDeLaVega added 2 commits May 29, 2024 15:22

feat(look-and-feel): adopt new folder structure + config for slash

32f8936

feat(look-and-feel) : create look and feel folders + config

42774ed

PeioDeLaVega force-pushed the release/2024.03.1 branch from 439f45d to 42774ed Compare May 29, 2024 14:26

pplancq approved these changes Jun 19, 2024

View reviewed changes

johnmeunier approved these changes Jun 24, 2024

View reviewed changes

jmraxa approved these changes Jun 24, 2024

View reviewed changes

mehdisebei mentioned this pull request Aug 1, 2024

Feature: Rename packages by slash #438

Merged

jmraxa closed this Sep 12, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(look and feel): create look and feel packages #227

feat(look and feel): create look and feel packages #227

PeioDeLaVega commented Mar 26, 2024

pplancq commented Mar 27, 2024

PeioDeLaVega commented Mar 27, 2024

pplancq commented Mar 28, 2024

samuel-gomez commented Mar 28, 2024

samuel-gomez commented Mar 28, 2024 •

edited

Loading

PeioDeLaVega commented Mar 28, 2024

pplancq commented Mar 29, 2024

pplancq left a comment

pplancq Mar 29, 2024

jmraxa Apr 4, 2024

pplancq Apr 9, 2024

jmraxa Apr 9, 2024 •

edited

Loading

pplancq Apr 9, 2024

jmraxa Apr 15, 2024

pplancq May 15, 2024

pplancq May 15, 2024

pplancq May 15, 2024

pplancq May 15, 2024

johnmeunier left a comment

jmraxa commented Sep 12, 2024

		"packages/look-and-feel/css",
		"packages/look-and-feel/react",

		- run: npm version ${{ steps.determine_version.outputs.version }} -w packages/look-and-feel/css -w packages/look-and-feel/react
		- run: npm publish -w packages/look-and-feel/css -w packages/look-and-feel/react --access public

feat(look and feel): create look and feel packages #227

feat(look and feel): create look and feel packages #227

Conversation

PeioDeLaVega commented Mar 26, 2024

pplancq commented Mar 27, 2024

PeioDeLaVega commented Mar 27, 2024

pplancq commented Mar 28, 2024

samuel-gomez commented Mar 28, 2024

samuel-gomez commented Mar 28, 2024 • edited Loading

PeioDeLaVega commented Mar 28, 2024

pplancq commented Mar 29, 2024

pplancq left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jmraxa Apr 9, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

johnmeunier left a comment

Choose a reason for hiding this comment

jmraxa commented Sep 12, 2024

samuel-gomez commented Mar 28, 2024 •

edited

Loading

jmraxa Apr 9, 2024 •

edited

Loading