Are we a lib or a framework?

[dmanners]

What the hell are we? I think this is super important as we move and grow. Do we build a KickAssCommerceLib that is a lib and then a KickAssCommerceFramework that is an example implementation of our own lib?

My definitions would be.

1. Framework tells you what tools to use and lets you use them,
2. Lib helps you do things in the tools you love best,

[adam-paterson]

You can use the Oro libs without the need for the full framework, same with Sylius. I think it's a good idea if we have a lib (or series of) to ease projects that don't need the full framework, or want to integrate KickAss into their existing architecture.

[adam-paterson]

Plus, the more repositories we have under the organisation the busier we look.

[sandermangel]

I agree, splitting it up would make sense since most frameworks do it. And indeed, looking busy is as always the key goal here. Some questions we need to answer in that case are

1. is it one big library or do we use smaller ones like Symfony
2. do they have their own SemVer version (yes of course they do)
3. where do we draw the line, how do we decide something should be a library since it might be useful for others
4. did we think of the overhead that multiple repos, versions, backwards compatibility etc brings?
5. would it be an option to introduce this later? So keep it in the back of our minds but only refactor before we move away form Alpha

[dmanners]

From a point 5 point of view we could use composer and paths.

Then have multiple modules inside one repo. Then after we are "done" extract them all, controversial I know but it might be a good start.

I do this with projects now I see there are 3 styles of repos and all have their own composer.json.

1. Public - nice and simple and in packagist,
2. Private but generic - under the company name but under our private satis server,
3. Private but project specific - under the project name under /src but included via composer using path.

[sandermangel]

I'm not sure I'm qualified to make a decision about this so I trust you guys ;)

[dmanners]

I would be happy saying for Phase1 - Alpha we build using composer path with a final task of making multiple repos. At this point it would be "easy" to extract as each module would be ready built.

[adam-paterson]

I agree, this is the approach I take for all other projects. There is no shame in publishing a pre-release on Packagist either to help with builds.

[dmanners]

@adam-paterson @sandermangel have a look at https://github.com/KickAssCommerce/KickAssCommerce/pull/22 and see what you think!

[adam-paterson]

@dmanners After some playing around I think we should structure ourselves like Laravel and Symfony do.

The main changes would require use to:

• Create a kickasscommerce/framework repository
• Keep this repository for application specific logic

If we have create the framework repo we can build our components as we are now in src/<COMPONENT> each with it's own composer.json and requirements, etc.

The classmaps can be achieved using the following trick with composer

...
"replace": {
    "kickasscommerce/auth": "self.version",
    "kickasscommerce/something": "self.version"
}
...

This would use the namespaces defined in the "sub-modules" composer.json. When we have an official release, we can publish them as read only repositories for others to use (if we come up with anything genius people can use outside of our project)

The kickasscommerce/kickasscommerce repo would then only require kickasscommerce/framework which will bring in everything. It would allow people to build their own applications using our framework as a base, without bringing in Slim, etc.