Fix CodeSandbox examples

[kennedybaird]

Using examples/usecase-todo to change the examples approach to solve for codesandbox issues.

1. Moving to devcontainers as codesandbox is stopping supporting sandbox.config.json
2. Hardcoding seed data in the example, whilst keeping the seed-data command
3. Setting prisma to inherit versions
4. Removing postinstall to avoid possible conflicts with prisma minor patch changes to their generator

To solve for the examples snapshot tests:

• leaving the schema's in the example's folder
• adding a new test:monorepo-snapshot-test command to replace postinstall
• added a new test:examples-snapshot-tests to root package.json which targets the above command recursively in all examples folders
• added a new examples_snapshot_tests test to ci to run the above command once

This is going to significantly reduce the time for actions as each of the smoke tests currently runs the postinstall for all the examples each time (~5m).

This approach also allows us to handle framework-nextjs-two-servers as well.

[codesandbox-ci[bot]]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit b23b8494dbef21b5c64856b98647686156aeb0ce:

Sandbox	Source
@keystone-6/sandbox	Configuration

[dcousens]

Seed data - I think it's best if we just stop ignoring the example.db files

Honestly, I think this is a good approach. We do this already, and it's solid.

The primary downside I can see is the lack of human readability for the binary file on GitHub. We otherwise have the examples/script example to showcase data seeding.

[dcousens]

Maybe we can build the keystone.db files deterministically from our root scripts/ folder?

[kennedybaird]

Seed data - I think it's best if we just stop ignoring the example.db files

Honestly, I think this is a good approach. We do this already, and it's solid.

The primary downside I can see is the lack of human readability for the binary file on GitHub. We otherwise have the examples/script example to showcase data seeding.

The intention was to still have the needed seed-data files, but have the database seeded for the first run

[kennedybaird]

Maybe we can build the keystone.db files deterministically from our root scripts/ folder?

A script to do this would be fine, if you were interested in that then I would be considering resurfacing my previous script from #9266 but removing the versioning.

An iterative script would solve for a few problems, but I went the other route based on the previous feedback.

[kennedybaird]

(original PR content)

This would be my suggestion to solving CodeSandbox - and versioning with prisma in particular.

CodeSandbox was supposed to end support for sandbox.config.json at the end of '23, so moving to devcontainer is needed. Removing the postinstall command is needed to fix for the prisma versioning issue.

Seed data - I think it's best if we just stop ignoring the example.db files

To solve for schemas potentially being different based on the prisma version we:

• set the prisma versions to * to inherit from keystone/core
• add the schema files to .gitignore so that they are always recreated on the respective machine, using the relevant prisma version from keystone

If we're happy with those conditions, I can go through and update all the examples to this new approach.

[kennedybaird]

@dcousens - I think I've found a reasonable solution, have updated the PR.