Move muban-core and muban-transition-component to muban with a lerna monorepo setup

[skulptur]

Having muban and muban-core live in the same repo could help us moving forward by allowing us to more easily integrate features that span both projects, as well as adding new related packages without having to create and manage multiple repos.

Also, consider using a namespace @muban for packages.

[ThaNarie]

muban should be considered a boilerplate/skeleton, not a "library" with versioning etc.

It should be testable and cloneable as a project.

If you want to do it properly, you would need something similar to react-scripts in create-react-app, so more of the muban build system can be its own package, while still allowing flexibility in projects through configuration or ejecting. Which is a lot of work!

But having a way to consolidate feedback/issues/etc in a single location would be beneficial, including package namespace.

Happy to hear your followup thoughts about it :)

[skulptur]

I understand that Muban in itself is currently not a package but rather something that we clone and go to town.

Since we are drawing the parallel, React and Create React App actually live in different repos, even though React itself has a lot of packages in the React repo. It makes perfect sense for React as a library, to have the starter as a completely separate project.

In their case though, React itself is the main product and usable in isolation. Muban as a project is a mix of several things. It's more than a boilerplate. It's an opinionated selection of technologies and a way to develop and build them. React can be used without Create React App. Muban without the build pipeline and glue, is not tangible.

So what we do depends also on where we want Muban to go. Is it ever going to be a library that we realistically use in isolation of its boilerplate? Then I agree we should go the React way. Otherwise I think we can make things easier for ourselves going forward by having a single repo.

For simplicity we could have the root of this repo contain 2 dirs and a readme pointing to each. One holds muban-skeleton and the other holds the lerna setup with the packages.

[ThaNarie]

Muban-core could be used perfectly in isolation for simple server-rendered pages that need an easy way of making components interactive, and binding them to the HTML.

The main reason muban should be considered a boilerplate, is that there is no real versioning, no upgrade strategy, changes are not backwards compatible.

Once you started a Muban project from this repo, you cannot easily update it a year later.

Compare muban to vue-skeleton, which as a complete webpack setup, default routes, language loading etc.

Of course it's not the same to either vue-skeleton, or react / CRA - but that's because muban is a completely different thing.

Adding to this, and going a step further in the opposite direction, there are cases where we would need different versions of the skeleton, as separate existing repos:

• when using twig instead of handlebars as template language, while still keeping muban-core as-is
• when doing the https://github.com/mediamonks/muban/tree/feature/traditional setup, that completely changes the way it's built, but with the same intent and muban-core in place

But so far we haven't done so, since it's tricky to maintain multiple boilerplates. So when it's possible to move some common code and build tools that might be shared between the two in packages, it could become easier to do exactly that.

[skulptur]

I agree. Closing.