With Windows the order of the imports was not the same as with Linux,
this was causing the linter to fail with CI.
We force the import starting with ":" to the internal group to fix this
issue.
Major Changes
- The first bunch of components and features are ready,
the first milestone has been reached
Minor Changes
- 9edb976: Position Datepicker popover on top or bottom depending space
available
Patch Changes
- fd7ad8a: Do not apply font-family to all elements with `*` selector
If we work from an app perspective, it is nice to have a watch mode
on our packages to see the changes in real time. Better to use the
watch mode of vite (rollup) compare to nodemon because it is faster,
we re-transpile only the files that have changed.
Possility to use the wath mode by polling as well, on a remote machine
the HMR does not work well, the polling mode helps to solve this issue.
Working on the date picker, we looked for an headless
UI components library. React-aria was chosen to support
the new form's component development. They developped a suite of
headless UI components that seemed quite easy to style.
Previously we were using standard Roboto Font but we were struggling to
get the same boldness as the ones from the Figma sketches. It appears
that Figma uses Roboto Flex, so by installing it we can now nearly
perfectly align our visuals with the ones form the sketches. I had to
do some custom tweaks with the weights of the font because if we
use exactly the same font-weight as in Figma the render is still different.
At first we wanted to only support ESM. But as we want to share types
and export design tokens from the react package to the outside world
in order to allow local cunningham.ts files to import them, we are
forced to also build the library for CJS too. Why? Because local
cunningham.ts files are loaded as CJS, so they can only import CJS
module. Why loading cunningham.ts as CJS? Because the tokens package's
binary is built for CJS, then it's seamless to make it load CJS, where
making it load ESM was buggy. And why not migrate the tokens package to
ESM so? Because it implies to rewrite every imports with .js extensions,
makes us loose the possibility to use __dirname kind of variables. And
also Jest use for testing is not compliant at all when it comes to execute
ESM code. Well, the ecosystem is not ready for that at the moment, sadly.
The static storybook deployment to github pages was throwing 404 errors
for a file beginning with a underscore, adding a .nojekyll disables
conflicts due to the default behavio of github pages.
The package @storybook/storybook-deployer that seems to not directly work
with Storybook 7 was expecting that command named "build-storybook" to
exist. With the bin updates of Storybook 7 this bin does not longer exist,
so I created a specfic script inside package.json that is named
"build-storybook" too in order to make everything work. Also now that
Storybook uses directly the local vite config, the fact that our config
generates types was causing issues when building Storybook, that why
we filter plugins in main.ts in order to remove "vite:dts".
Previously we had some configuration in package.json that were falsely
indicating that the react package was supporting CJS, which wasn't the
case. So this commit makes it clear that the package is pure ESM.
Previously types file were splitted into their original folder
tree structure. By enabling this option we could just get one
global .d.ts file. To make this more handy I created a dedicated
build bash file, the package.json was starting to get messy.
