https://next.yarnpkg.com/getting-started/install

I find it sill concerning that we have the yarn binary (.yarn/releases) in our repository. If we all install volta we can pin node and yarn to a specific version without hosting yarn ourselves.

What do you think?

We can base it on the following setup form tsdx:

https://github.com/jaredpalmer/tsdx/blob/ce3ff8e23b77515ca09d32cb01273531acebf9ab/src/createJestConfig.ts#L5-L19

Also, install @testing-library!

closes #8

Should we move theme(s) to their own workspace? E.g.

/packages
/theme
  b2b-reservix
  unicorn

If the button component is ready to use, we can add this as example in box doc.
Actually the box doc is without code examples.
#92
#93

• examples (e.g. simple button)
• usage with theme (themeSection + variant)

yarn init!

• create label component
• create story file
• create a test
• create index file

Thank's to: #97

https://www.figma.com/file/DFKyTGHAoDxOsUBPszLLxP/%F0%9F%8F%B5%EF%B8%8FMarigold?node-id=428%3A267

We want to have the option to easily switch themes within storybook. This can be done via addon. There is already one called storybook-addon-themes can we use this? If not do we have to write our own :(

https://www.npmjs.com/package/storybook-addon-themes

• add marigold description
• make badges more beautiful

I am not sure wether we should write tests for themes. The base theme already has specifications for writing a theme. Maybe its useless to test an object. Coverage always shows that the themes are not tested. I think we have three options:

• we let it be as it is
• exclude theme files from coverage check
• write tests for the themes

Also:

Can we use tsdx test and tsdx lint with our configs and drop some depencies?

There are three ways I can think of all follow the principle that components are not providing surrounding white space (a.k.a margin/padding).

1. <Space> component

There is exactly one component that can add white space. There is no abstraction for spacing, just use margin/padding. It has to be inserted everywhere where space is required.

<Box>
	<Space mt={["medium", "large"]}/>
	<Box></Box>
	<Space my={["medium", "large"]}/>
	<Box></Box>
	<Space my={["medium", "large"]}/>
	<Box></Box>
	<Space mb={["medium", "large"]}/>
</Box>

2. "Space Props"

Every component of the design system exposes spacing props. They have to be applied on component instance basis.

<Box>
	<Box my={["medium", "large"]}></Box>
	<Box mb={["medium", "large"]}></Box>
	<Box mb={["medium", "large"]}></Box>
</Box>

3. Using dedicated layout components

This is what Braid does. You can find more info about the reasoning in this talk.

The gist is that they have dedicated components for the different layouts (e.g. horizontal, vertical, grid, ...). This results in extra HTML elements, but is less verbose in my opinion.

<Stack space={["medium", "large"]}>
	<Box></Box>
	<Box></Box>
	<Box></Box>
</Stack>

Reach-UI has incredible typings. We could steal + adapt the following typings for us to make creating components easier regarding typings:

https://github.com/reach/reach-ui/blob/4cb497f530b0f83f80c6f6f2da46ab55b1160cb6/packages/utils/src/index.tsx#L185-L209

/**
 * This is a hack for sure. The thing is, getting a component to intelligently
 * infer props based on a component or JSX string passed into an `as` prop is
 * kind of a huge pain. Getting it to work and satisfy the constraints of
 * `forwardRef` seems dang near impossible. To avoid needing to do this awkward
 * type song-and-dance every time we want to forward a ref into a component
 * that accepts an `as` prop, we abstract all of that mess to this function for
 * the time time being.
 *
 * TODO: Eventually we should probably just try to get the type defs above
 * working across the board, but ain't nobody got time for that mess!
 *
 * @param Comp
 */
export function forwardRefWithAs<Props, ComponentType extends As>(
  comp: (
    props: PropsFromAs<ComponentType, Props>,
    ref: React.RefObject<any>
  ) => React.ReactElement | null
) {
  return (React.forwardRef(comp as any) as unknown) as ComponentWithAs<
    ComponentType,
    Props
  >;
}

Do we want to move the monorepo structure to Github?
(With at least the "components" and "system" package?)

• package.json
• lerna.json
• create package components with package.json
• create package system package.json
• create README for every package

Before a PR can be merged the could should be correctly linted. Therefore, we need a job that checks for lint errors.

We used this as config:

{
  "useTabs": false,
  "singleQuote": true,
  "trailingComma": "es5"
}

Make sure people get promoted to install prettier/eslint plugins.

-> .vscode/extensions.json

{
  "recommendations": [
    "esbenp.prettier-vscode",
    "dbaeumer.vscode-eslint"
  ]
}

Figma Design

Setup storybook to work with:

• typescript
• see if @storybook/addon-docs is an option for documentation
• make example story using https://storybook.js.org/docs/formats/component-story-format/ (as a smoke test)

The dependencies in our root package.json grow very fast and it not easy anymore which dependencies are doing what and where they belong to.

To counteract this we could move configurations to a dedicated package (something like this). This would not remove any dot files in the root directory, but it would bundle dependencies with their corresponding tool. (e.g. all the webpack loaders that are required by storybook).

Initial version of a provider should include:

• Wrapping emotions context
• Allow to pass a theme to emotion (so the <Box> can pick it up)

Configure eslint based on CRA and with support for jest and prettier.

I'm unable to create and edit Milestones or create and attach Labels to Issues with only Member permissions.

• Exposes the common system props (see #85)
• Grabs CSS from a dedicated theme section (e.g. text)
• Add styles from design system to the B2B theme
• write tests for Text component

• Setup publishing @marigold packages to npm (and Github?).
  We can either use lerna or changesets (if we use the later, maybe we can ditch lerna?)
• Should only publish if test succeed

What's in the Box!!!

Initial documentation for the <Box> component. The following things should be included:

• difference between theme/css prop/style props/base styles
• application order of theme/css prop/style props/base styles
• as property

Basically:

1. `yarn add pretty-quick husky --dev``
2. Then add this config to package.json:
   { "husky": { "hooks": { "pre-commit": "pretty-quick --staged" } } }

https://www.conventionalcommits.org/en/v1.0.0/

Compare theme-ui, seek-oss Boxes.
Collect ideas what the Box should (not) do

• write test cases for box

Create the standard Button Component outlined in the Figma Button design.

Sizes:

• Large
• Small

Variants:

• Primary
• Secondary
• Ghost

By "design principles" I mean on a technological level, not design design.

When we really start to do some documentation, I guess we also need to tell people about the philosophy and our thinking behind the components and their API. For example, why did we chose the "Box-principle" or why do we use layout components (#118)?

This issue should be used to collect these things. I'll update the description based on our discussion below.

Structure

Let's plan a structure of the docs first:

INTRODUCTION

• Getting Started (#1744)
• About (#1761)
• Design Principles
  • strict vs flexible API
  • style props + variants + theming
  • composition
  • a11y
• FAQ
  • What are Design Systems (#1752)
  • Why is component X missing?
  • Why React?
  • Why emotion (or CSS-in-JS)?

CONCEPTS

• Primitives
  • Box
• Styling
  • Design Tokens
  • CSS-in-JS
  • Responsive Values
• Layout
  • isolated layouts (margin considered harmful)
• Theming

We should deploy storybook (as part of publishing?). But where? Netlify? GH Page?

Add the ability to display icons in the standard Button Component as outlined here.

Sizes:

• Large
• Small

Colors:

• White (Primary & Secondary)
• Black (Ghost)

We should establish some minimal guidelines before going into writing actual components.

Here are some ideas:

API

• We should expose the spacing style props
• We should expose the as prop
• We should expose the variant prop

Misc

• We should have a11y in mind and support some level of ARIA Standard

Can we use tsdx to build prod and dev?

The pipeline failes because of taking more than 10 minutes to deploy_storybook.
"Too long with no output (exceeded 10m0s): context deadline exceeded"

I think we have two options:

• we need to either increase the output timeout
• add some dummy output so that the task is not killed

• CI is closer to the repo and code?
• easier? better docs?
• Just pick everything from this list: https://github.com/sdras/awesome-actions

Or does Github do this now for us???

Also: https://renovatebot.com/

---> check which is the best tool

In addition to the test + coverage jobs, we should also check if typings are correct before a PR can be merged.

Basically this command should be executed:

tsc --noEmit

After #44 add a theme for Reservix (B2B) to packages. The design tokens can be found in our confluence. @Toshibot if you can find them 😄

https://allcontributors.org/

Figma Design

Figma Design

Follow up of #100

The theme introduced in #96 should be hosted in its own package.

Meeting to resolve open questions and define documentation rules, workflow, responsibilities.
All documentation in Confluence.
https://confluence.rsvx.it/display/DESIGN/Workflow