RFC: Merging all repos into one

[eric-burel]

Describe the problem you want to solve or enhancement you want to bring

Development of Vulcan NPM can become tricky when you want to experiment it in a real app, like in Vulcan Next. We need to use Yalc etc.

Having only one repo containing Vulcan core logic (NPM) + demo apps (Next, Express, Gatsby...) makes it easier to develop the framework.

Cons: can't the monorepo becomes a mess of complicated apps?
Define relevant concepts

Blitz is structured as a monorepo but revolves a lot around the Next app. We'd want to do the reverse: putting Vulcan Next within the monorepo.

Describe your solution
We could have scripts to create apps, based on templates => npx create-vulcan-app next generate a Next app, a Gatsby app, etc.

We could also keep separate repos like Vulcan Next, but generate them automatically. So that developers can still simply clone Vulcan Next for instance and get the latest code.

Questions to the community

• What's your opinion?
• Are you ok with using commands to create the app like npx create-vulcan-app next?
• What would be your approach? Eg how do we setup the repo so you can do something like npx create-vulcan-app or npx vulcan create next?
• What would be your preferred syntax and behaviour?
• How can we handle folders that are app and folders that are packages within the Lerna monorepo? Install must not become a mess and build-time must not explode, so the app have to be kept kinda separate of Lerna.
• How do we plug the local packages? So that when we develop, the app automatically use the local versions of @VulcanJS packages
• If you want to contribute: try to setup a demo, for instance a very very simple Express app within the vulcan-npm monorepo.

[Neobii]

Vulcan next should be a separate monorepo from the vulcan-npm monorepo.
Pros

• Easier way to get started using monorepos with react, typescript, jsx etc build settings taken care of.
• Easier to have a vulcan-ish package ecosystem.

Cons

• Annoying if you want to move that package over to vulcan-npm from your vulcan-next mono repo ie would lose git history.
• One of the biggest issues between vulcan-meteor and vulcan-meteor-starter was making sure package dependencies were the same in both.

[eric-burel]

I've found out about a possible alternative, used by Symfony for instance:
they put the app in the monorepo, but deploy a read-only repo for the actual app.
This way I could keep "vulcan-next" github project as an entrypoint but have the code within "vulcan-npm" to make the development and testing easier.

It could be suited in our scenario, though not a top priority.

From: https://dl.acm.org/doi/pdf/10.1145/3328433.3328435

[eric-burel]

https://stackoverflow.com/a/49799881/5513532 this seems to allow to publish a subtree of git as another repo

I've started an Express starter, I'll use it as a test case before trying to move Next

Yalc is sadly raising some issues with build tools, that wrongfully detect the symlinks as relative imports, it happens in Next
Not sure a monorepo would completely fix that but at least it could make things simpler