README

[b4stien]

(Cette PR ne doit pas être accepté, le README est dans le corps de la PR, pas dans le code)

Contexte (Pourquoi ce fork ?)

Create React App (CRA) ne permet pas d'avoir plusieurs entrypoints, cf react#1084, ce qui ne correspond pas à notre besoin d'avoir un service worker custom.

Ce fork ajoute donc un second entrypoint pour le service worker.

Comment ça marche ?

react-scripts (un sous package de CRA) contient une config webpack que l'on vient modifier pour avoir deux entrypoints (ce que webpack permet nativement). On modifie aussi les quelques fonctions et helpers de CRA qui s'attendent à ce que la config webpack soit un "objet de config" alors que la notre est un "tableau d'objet de config".

Comment on dev ici ?

On suit les releases de CRA par le process suivant :

• On fait en sorte que master ici soit à jour avec master upstream (celui de Facebook).
• On crée une branche upstream/X où X est la nouvelle release de CRA que l'on veut utiliser (eg: X est 3.3.0) dont le HEAD (le dernier commit) est le commit de la release de Facebook que l'on retrouve sur https://github.com/facebook/create-react-app/releases (eg: pour 3.3.0 il s'agit de react@9a817dd).
• On crée une branche oh/X dans laquelle vont se trouver nos modifications par rapport à upstream/X. S'agissant de ces modifications, la plupart du temps on peut les récupérer de la version précédentes, par exemple en partant de oh/X-1 et en y mergeant upstream/X.
• On crée une PR ici qui demande à pull oh/X dans upstream/X pour pouvoir consulter facilement les changements (on laisse cette PR ouverte sans la merger, c'est uniquement dans un but de consultation).
• On publish les packages modifiés, il s'agit en théorie de react-scripts et de react-dev-utils, avec le schema de versionning de nos forks ou major.minor.patch devient {major-sur-3-digits}{minor-sur-3-digits}{patch-sur-3-digits}.{oh-minor}{oh.patch} (eg: 3.3.0 -> 3003000.0.0).