Refactor to use Pota

[psimk]

I was initially tasked with solving the performance and stability issues with the existing skeleton, however as we are currently transitioning all of Media.Monk's skeletons to Pota, I figured that I can also transition the muban-skeleton right away.

Why Pota?

From internal discussions I discovered that internally we will require at least one more Muban Skeleton, so using Pota allows the new muban-skeleton to be extensible. Additionally, there is a number of other benefits introduced by Pota:

• upgradable skeleton build tools
  • this is possible because we are extending Pota's webpack-skeleton
  • also means that the muban-skeleton does not have to worry about updating or maintaining the base webpack configuration and we can focus on muban-specific configuration.
• can utilize @pota/create
• custom commands can be defined and used by @pota/cli, which allows defining custom arg options (no more env variables!)

What are the changes?

⚠️ Switching to Pota also means that we are dropping support for yarn and using npm is now required ⚠️
As we are now extending the webpack-skeleton, we are also inheriting its configuration. These are the most notable files/configuration options that are now inherited:

• .browserslistrc -> package.json["browserslist"]
• tsconfig.json
• babel.config.js -> handled by webpack-skeleton's webpack configuration
• following scripts are now added via @pota/create from `webpack-skeleton:
  • dev
  • format (used to be prettify)
  • typecheck (use to be check-types)
• build:preview has been removed in favor of npm run build -- --preview (pota build --preview)
• analyze has been removed in favor of npm run build -- --analyze (pota build --analyze)

The locations of static assets have also been changed:

• The main muban app build's static assets are now located in the root /static folder (previous /src/public/static).
• The pages (preview) build's static assets (including .html) are now located in /src/pages/public (previous src/pages/static & /scripts/devserver/index.html).

For consistency with other Pota skeletons the entry files have been renamed to main.ts. Additionally, the pages (preview) build's /src/server-bundle.ts has been moved to /src/pages/main.ts.

---

The general stability 📑 and performance 🏎️ is also greatly improved as we are now letting webpack handle page (preview) generation.

---

How can I test this out?

You can already setup a project from the new skeleton using @pota/create:

npx @pota/create@latest git@github.com:psimk/muban-skeleton.git#feature/pota-conversion my-muban-app

If you want to make some changes to the skeleton and test it out locally:

npm pack # package the skeleton into a '.tgz' file
npx @pota/create@latest ./muban-skeleton-1.0.0-alpha.1.tgz my-muban-app # run `@pota/create` with the packaged skeleton

Okay, when can we merge this?

The transition is not fully complete and I will continue updating this PR, here are the remaining todo's:

• implement patches from /patches into their respective packages
  • story context (@muban/storybook)
  • cjs iframe entry (@storybook/builder-webpack5, requires Core: Rename generated-stories-entry to cjs extension so require works storybookjs/storybook#16727)
  • package name length check (@storybook/core-server)
• update documentation
• add monck support
• test on existing projects
• fix eslint issues
• add deploy command (needs to be done in webpack-skeleton)
• review bundle output for potential improvements
  • replace classnames with clsx

[ThaNarie]

Found an issue with the template rendering and HMR;

1. run dev
2. modify a component template to cause a runtime error (e.g. change the getButtonLabel inside ToggleExpand.template.ts to something that doesnt exist)
3. observe HMR errors in the console
4. revert the error in the template
5. observe [webpack-dev-middleware] wait until bundle finished: /index.html in the console
6. any changes to the page data or template are not picked up anymore

[psimk]

@ThaNarie
The issue should be fixed, it occurred because the MubanPagePlugin wasn't handling errors thrown either by loading the template files or calling their factories. As long as the initial build is valid and without errors, then that will be used as a fallback for any error cases.