Split addon into multiple packages

projectcaluma / ember-caluma

Ember.js addons for Caluma

https://docs.caluma.io/ember-caluma/

GNU Lesser General Public License v3.0

18 stars 22 forks source link

Split addon into multiple packages #394

Closed anehx closed 2 years ago

anehx commented 5 years ago

It would be nice if we could split ember-caluma into multiple packages, since one may not want to use all of the code. Since we want to have a monorepo, we could use https://github.com/lerna/lerna for handling dependencies and publishing..

My suggestion for the new packages is the following:

@projectcaluma/ember-form, the form rendering components and services
@projectcaluma/ember-form-builder, the form-builder engine
@projectcaluma/ember-core, basically the addon/lib folder.
- Here we could also think about moving to native classes so we'd have a standalone solution
@projectcaluma/ember-test, mirage stuff for testing, or in the future factories for the core models

Problems being solved by this:

The user can decide what he needs -> smaller payload
Improved dev sanity by separating unrelated code
Central dependency management by https://github.com/lerna/lerna

/cc @czosel @fkm

fkm commented 5 years ago

I'm still rather new to Ember. But how would outsourcing tests work? Don't they need to be in the "project"/repository?

czosel commented 5 years ago

How would the naming concept look if we want to account for other frameworks in the future? I’d like to have framework-independent packages like @caluma/core and framework-dependent ones like @caluma/ember-form ... or maybe @ember-caluma/form ?

fkm commented 5 years ago

What kind of framework do you mean?

PS: The @ is the organisation name. So @caluma or @projectcaluma.

anehx commented 5 years ago

I'm still rather new to Ember. But how would outsourcing tests work? Don't they need to be in the "project"/repository?

I was not talking about the tests but about the test helpers, which currently consist of our grapql-mirage layer. However, we are planning to provide factories for the objects of our lib layer..

Outsourcing the helpers would free our codebase from code that most of the users don't need.

anehx commented 5 years ago

How would the naming concept look if we want to account for other frameworks in the future? I’d like to have framework-independent packages like @caluma/core and framework-dependent ones like @caluma/ember-form ... or maybe @ember-caluma/form ?

Agree. Since the @ part is the org we'd name it something like @projectcaluma/ember-form and maybe @projectcaluma/core for a framework agnostic lib layer in the future..

Edit: updated the description

anehx commented 5 years ago

What kind of framework do you mean?

PS: The @ is the organisation name. So @caluma or @projectcaluma.

The vision of the client side part of caluma is, that there are libraries for using caluma in various frontend frameworks like Vue.js, React or Angular.. Ember.js is just the beginning!

anehx commented 2 years ago

Resolved in #1507