A better web dev environment for all
It should be easy to share code, but it's not. Cloudpack aims to make sharing code easier by standardizing how inner-loops work for apps in a way that allows for any dependency to be side-loadable and testable in any app without rebuilding the entire project.
WARNING
This page is a work in progress.
Goals
- Help simplify the cross-repo code sharing challenges
- Devs can easily test any package change in any of their consumer apps.
- Abstract the tooling to allow for it to evolve
- Avoid the "webpack config" problem; limit the ways to do things so that things can be improved over time, and avoid bundler-specific configuration.
Future/aspirational goals:
- Cross-repo code sharing:
- Devs can easily discover which apps consume their package.
- Abstracting tooling:
- Upgrading your tool chain should have a "fix" mode to apply transforms on your project and code
- Standardize the workflows so that devs can predictably get up and running:
- All rules are enforced through conformance validation
- Every application should be testable with
yarn start - Every library should be buildable with
yarn build - Every application or library can run integration testing with
yarn test
- Enforce conformance in the packages; things should work the same across projects
Principles
- Minimize API surfaces
- Convention over configuration
Problems
Testing shared code across repos is hard
At Microsoft, we build many large-scale web apps comprised of thousands of packages which are built across many private and public repos.
When features are built or bugs are fixed which need to cross repo boundaries, things become difficult fast:
- Devs build the feature or fix the bug in isolation in the root package.
- The change needs to be reviewed, tested, merged, and published.
- The package's new version now need to be picked up by the next consumer: A min semver must be updated. Code changes may be needed to consume the new version.
- The change in the consumer repo needs to be reviewed, tested, merged, and published/deployed.
- Repeat step 3 and 4 until the application has been finally updated with the change.
This process is difficult and error prone:
- If it's hard to make and verify updates, consumers don't udpate their dependencies as often, making future updates even more challenging.
- The less test coverage consumers have, the easier bugs get in.
Developers need tools that enable them to quickly make modifications anywhere, and see the effects in and run tests against any app.