Adopt a monorepo structure

💡 Idea

Adopt a monorepo structure

Motivation

Today, the project is composed of multiple package.json files, both installing different versions of the dependencies (mostly devDependencies). It would be great, when possible and wanted, to adopt a monorepo structure as offered by yarn.

Example

• With Yarn: https://classic.yarnpkg.com/blog/2017/08/02/introducing-workspaces/
• With Lerna: https://github.com/lerna/lerna

[waynevanson]

I haven’t used lerna, but I’ve used yarn and it’s delightful.

A few notes to consider if not already considered:

• Each package should have it’s own label in issues.
• Pull requests should be minimal as merge conflicts are a pain from my experience. There are 2 pulls at the time of writing this! (y)
• Changes don’t have to be breaking, as along as no one is using GitHub as a CDN.

[dubzzz]

Plan is to adopt Yarn 2/3 as the package and workspace manager backing fast-check. As our initial attempt failed because of our nested structure of packages not being proper workspaces, we will:

1. adopt a structure close to a monorepo by only moving files and updating scripts accordingly
2. adopt yarn 2/3
3. switch to monorepo philosophy (possibly included in 2)
4. move ava-fast-check and jest-fast-check here (fix original repos first to support v3)

Concerning 1, the target structure is the following:

• codemods/
  • unify-signatures/
    • src/
    • test/
• examples/
• e2e/
  • test-esm/
  • test-types/
• packages/
  • fast-check/
    • src/
    • test/
  • ava/
  • jest/

The e2e/ is inspired by the test/ within babel.