Comments (9)
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.
- Public - nice and simple and in packagist,
- Private but generic - under the company name but under our private satis server,
- Private but project specific - under the project name under /src but included via composer using path.
from kickasscommerce.
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.
from kickasscommerce.
@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.
from kickasscommerce.
Plus, the more repositories we have under the organisation the busier we look.
from kickasscommerce.
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
- is it one big library or do we use smaller ones like Symfony
- do they have their own SemVer version (yes of course they do)
- where do we draw the line, how do we decide something should be a library since it might be useful for others
- did we think of the overhead that multiple repos, versions, backwards compatibility etc brings?
- 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
from kickasscommerce.
I'm not sure I'm qualified to make a decision about this so I trust you guys ;)
from kickasscommerce.
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.
from kickasscommerce.
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.
from kickasscommerce.
@adam-paterson @sandermangel have a look at #22 and see what you think!
from kickasscommerce.
Related Issues (20)
- The repo knows to much
- We suck at FE HOT 1
- We suck at designing logos HOT 6
- Lots of * in the composer.json HOT 1
- Add build processes and code checks to the repo
- Standardise APIs HOT 2
- Invalid cache key HOT 1
- Is AOP a bad thing? HOT 6
- Is SlimPHP the best solution for routing HOT 1
- Session data - how do the cool kids/frameworks handle that? HOT 1
- A bit of admin HOT 7
- Move Moltin bridge to it's own repo HOT 1
- move to Moltin V2 API HOT 3
- Composer.lock should be not in the repo, the project should require PHP 7
- Add in some easy to use DI HOT 13
- Make maps Immutable HOT 2
- Add fancy interceptors HOT 1
- Remove hardcoded dependencies to Moltin in router HOT 3
- Make the cache interceptor wrap bridge class methods instead of repositories
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kickasscommerce.