Hyperapp: Monorepo?

Created on 24 Dec 2017  路  11Comments  路  Source: jorgebucaran/hyperapp

Today the official Hyperapp ecosystem consists of four different repositories hosted in the same organization. The supporting libraries all have devDependencies and peerDependencies on particular versions of hyperapp that need to be kept up-to-date. Managing them all as a single repository would allow for refactoring/testing/releasing compatible versions of all at once. Perhaps this coordination isn't too painful with four packages, but it's still there.

Monorepos are already used by many successful projects like Babel, React, Angular, Ember, Meteor, Jest, and others. If we decided to move forward with this approach, there are tools to assist with managing multiple packages in a single repo such as Lerna.

Community Discussion Wontfix

Most helpful comment

Keeping the repositories separate seems fine. Especially now that the API is likely to be stable.

All 11 comments

I don't understand what problem "monorepos" are trying to solve.

@JorgeBucaran I don't understand what problem "monorepos" are trying to solve.

It's similar to the differences between a monolith app architecture vs microservices. If the different packages are isolated enough to minimize dependencies (both literal code and in terms of testing) then it's more of an issue of style/management than a technical problem.

Even though our libraries do have some interdependencies, I'm not currently convinced that moving to a monorepo would be an improvement. I was mostly bringing this up since this is a common practice I have seen on other projects and I hadn't seen a discussion on it here before.

I vote no. Our current structure works, and I have seen a lot of orgs work like we do. Especially Vue/Webpack 馃帀

Does anyone else want to weigh in on this, or are we unanimous and should close?

@lukejacksonn @SkaterDad Ping.

Also _poke_ @Alber70g who 馃憤 'd this

And @BenGale too

Keeping the repositories separate seems fine. Especially now that the API is likely to be stable.

In retrospect I'd say it'd be better to have it when the API was still in 'breaking' mode. Right now I still think it would be nice to have it all together and releasing using Lerna. But it's more of a "niceity" than a necessity.

Unless of course we're already planning on version 2.x and we want to create a 2.0-alpha. Then it's nice to have it all toghether so we can update the several packages in one go. I.e. in the same PR as we introduce the breaking change

I like @Alber70g suggestion, so maybe let's revisit this when we start thinking about 2.x? 馃

Considering how simple Hyperapp is, both the source code and the bundling step (we are not even using a rollup config file!) I think that introducing a Lerna is unjustified.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Mytrill picture Mytrill  路  4Comments

dmitrykurmanov picture dmitrykurmanov  路  3Comments

zhaotoday picture zhaotoday  路  3Comments

jorgebucaran picture jorgebucaran  路  4Comments

jorgebucaran picture jorgebucaran  路  4Comments