| codesandboxER | codesandbox-client |
|---|---|
| bolt monorepo | lerna monorepo |
| Packages are designed to be publishedin close to lockstep, often simultaneously, and interdepend very closely - symlinking them is very important to dev flow | About half of the components are not published. Things that are published can mostly be published individually |
| Publishing is super easy - except for exceptional packages (vs-codesandboxer and atom-codesandboxer) | ??? (It looks like you would cd in and manually publish? |
| Build process and debugging requires building some packages, even if you are working on another package. | ??? |
| Documentation is in READMEs, really wants a website with better info/examples. Was recently told they were confusing. | Docs are built into codesandbox website, and are good. |
- Would it be worth having a codesandbox org on github? Would be a good intermediary step towards a core shared repo.
- Distinguishing between packages published to npm, published otherwise (browser extension, vs-code package, atom package), and packages not published (website bits) would be neat.
- You should probably have publish rights to codesandboxer and related packages - to make sure you don't get blocked there. Maybe put them under the org to make that easy? That would mean changing the preferred canon names.
My major work project at the moment is sort of build and docs tooling - the atlaskit website, but also some technologies around that. The person who sits behind me at work is maintaining bolt, and I got super-heavily involved in making this https://www.npmjs.com/package/@atlaskit/build-releases to manage builds.
I'm kind of keen to see how well these work in more places and am super-biased here.
Followup package breakdown:
codesandbox-api@codesandbox/react-embedreact-smooshpacksandbox-hookssmooshpacksse hookscodesandbox-browserfsmonaco-editormonaco-typescriptvscode-editorcodesandboxercodesandboxer-fsreact-codesandboxervs-codesandboxeratom-codesandboxerbitbucket-codesandboxer