Move example app from monorepo to its own repository

[ricardovdheijden]

Move the example app from the mono-repo to its own repo to its own repo

• Create new repo for example app and move code from mono-repo to example app repo
• Link example app repo to the mono-repo using git submodules
• Copy package.json from mono-repo build folder to example app repo
• Decide if NX should generate a package.json or should use a predefined one

[acidjunk]

https://nx.dev/concepts/integrated-vs-package-based

[ricardovdheijden]

Checklist from the migration PR:

• [x] Merge branches into nx repo (the localization branch needs to be done manually)
• [x] Copy all component files + App files over the files in the Turbo repo (so you have the latest changes there
• [x] Throw away all NX config and package.json as well (in NX repo) -- moved to temp folder for now
• [x] Rename lib and app folders to match Turborepo: think about lib folder structure because it is hierarchically in a different place in the tree (you should mimic that first)

Copy all turbo config (from Turbo repo NX):

• [x] Setup TSC for app
• [x] Setup TSC for lib
• [x] Lint setup for app
• [x] Lint run for app (should be minimal chagnes)
• [x] Lint setup for lib
• [x] Lint run for lib (should be minimal chagnes)
• [x] Setup jest
• [x] Setup pre-commit hook
• [x] Update Github actions and move back into project root to activate the GH actions
• [ ] Storybook
• [x] Update readme to something usefull

[hanstrompert]

@acidjunk Decided that we leave the example app in the mono repo for now. Only just add a short README for users that want to copy the example app folder to a separate repository.

[acidjunk]

@hanstrompert I think with the work in #169 : you can just copy the standalone folder -> run a yarn install from that new folder. That will ask you which version of @orchestrator-ui@tsconfig, @orchestrator-ui@eslint and @orchestrator-ui/components you will want to install because there are now pointing to version "*" which the mono repo tools resolve internally. I thinks it's very handy to have the extra 2 packages also on npmjs: it now closely follows the design/vision as outlined in our confluence docs for 2.0 😎

SO: mission accomplished; you can install/test/use the standalone app, without the need for the other stuff in the mono repo.

I expect that the only downside of the new approach is the fact that hot reloading/fast refresh will work suboptimal when developing on both the library and the app at the same time. The page will reload. As I explained this morning in Slack: it should be possible to optimize that, during development, by either:

• symlink dist to ../ inside the package/components folder
• change the dist/index.js entrypoint in the package.json of the component lib to /src/index.ts

As we now use the actual minified build version of the lib during development; the current setup tests the integration in a very robust way. Still I can imagine that it would be handy to have a small test/github action, that tests if the standalone app can be build successfully (for example when we merge to main)