adonisjs / rfcs

💬 Sharing big changes with community to add them to the AdonisJs eco-system
52 stars 6 forks source link

Merging packages #2

Closed thetutlage closed 3 years ago

thetutlage commented 6 years ago

Brief

AdonisJs is a modular framework with several different packages combined together to create the final experience.

Over the course of last few years, I (author) have noticed, that some of the packages are must have in order to create a working web app. For example:

So instead of releasing them as separate packages, it is more convenient to merge them together and release them under a single package.

Also note, that AdonisJs is not express and also the philosophy is different. So if your use-case is so simple and doesn't require validation, bodyparsing, then it's better to use express over Adonis

What problem does it solve?

It will remove the versioning confusion from the framework. Right now, each package have their own versions and a combination of them makes the final version.

However, if we move all core packages into a single package, then we will just have to manage a single version. For independent packages, they can have their own versions.

Proposal

The proposal is to move following packages into one @adonisjs/framework.

Core

Other packages like lucid, websocket can still be separate and must mention that they support on @adonisjs/framework@5.0.0 and so on.

Are you willing to work on it?

Yes

assertchris commented 6 years ago

From a developer perspective; it would be great to not have to adonis install a lot of currently-optional components (and the associated changes to the provider list).

assertchris commented 6 years ago

We should probably expand the docs to demonstrate how to disable the features which have been rolled in but are still considered optional. I know it's easy or people already familiar with the framework, but it's flamebait not to address it at all...

diego3g commented 6 years ago

I still think it's better each package have it's own repository. It's easier to understand the code while creating new features and keep track of new changes. Merging all the packages will also merge issues, pull requests, versions, contributors... i mean, if it's not really bothering, i don't see much advantage joining them.

thetutlage commented 6 years ago

@diego3g Merging has certain benefits when creating releases. Since everyone look at AdonisJs as one piece, they have no idea which version of which package is part of Adonis 4 or going forward Adonis 5.

As far as issues are concerned, 95% of issues are created inside framework repo and then I have been moving them manually. Also if we will have proper labels in place, the issues can be filtered easily.

The packages I am merging are of same nature. For example: @adonisjs/framework has request/response objects, and @adonisjs/bodyparser needs them. So if I am changing API for request/response, I have to make sure to update bodyparser too.

Once these packages will together, the bodyparser code will fail writing away when running tests.

Finally, it will be lot easier to track the version of one single package and keep discussions, docs around that version number.

The other individual pieces like lucid, mail, websockets will still be different packages

PazzaVlad commented 6 years ago

Agree with Virk about version confusion, experienced that when firstly discover Adonis.

But maybe Drive and Ally can be as a separate packages, since they are not 'must have' for many web app?

mourad-ghafiri commented 6 years ago

hello;

is it possible to align all packages to the same major version number starting from 5.y.z

RomainLanz commented 6 years ago

@mouradghafiri38 Since we are using semantic versioning to "versionize" our packages we cannot have the same version in all of them.

mourad-ghafiri commented 6 years ago

same thing happned for angular at version 3... they skipped version 3 and aligned all angular modules to 4... so thought it will be a good practice for adonisjs to organize packages :)

bitkidd commented 6 years ago

Love the idea, feels natural as an approach to versionising, as Laravel, Rails and others do, packaging different modules in a stable block.