Skip to content

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:

  1. Devs build the feature or fix the bug in isolation in the root package.
  2. The change needs to be reviewed, tested, merged, and published.
  3. 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.
  4. The change in the consumer repo needs to be reviewed, tested, merged, and published/deployed.
  5. 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.