0

I have created a laravel 5.3 charity app

now the client tells me:

I want to have the same app again, but only for certain things, say, the same app but only for charity donations for nature. So new logo, different emails etc

what is a good way, to make it possible to share updates across the two apps without having to redo all commits and manually merge commits in each sub project?

I thought maybe some way where you have a core project, and separate git repo that only contains the files you want to overwrite in the said application... not exactly sure what tools to use etc or if there is something smarter.

EDIT I thought about creating from app A a service provider that includes everything of app A, make it available via composer package. Now app CLONE will use this service provider / composer package. When I make an update to the service provider of app A I just run a composer update in my cloned app. Problem: what if the update needs database migrations?

Toskan
  • 13,911
  • 14
  • 95
  • 185

3 Answers3

3

A good way to do this would be to set up two Laravel apps and then build a Composer package that contains all of the core components.

You can easily link to packages in Composer that are hosted in private repositories, bypassing Packagist entirely.

Setting it up in the composer.json file is quite easy. The app composer files would follow this sort of pattern:

{
    "type": "project",
    "repositories": [
        {
            "type": "git",
            "url": "git@github.com:your/package.git"
        }
    ],
    "require": {
        "your/package": "dev-master",
        ...
    }
}

While the common package would follow this:

{
    "name": "your/package",
    "autoload": {
        "psr-4": {
            "YourPackage\\": "src/"
        }
    }
}

Then just commit any common classes/helpers into the your/package.git repository, and you can easily access them in both.

Stephen RC
  • 1,494
  • 2
  • 19
  • 34
  • thinking about this again, I seem to have trouble defining what is core. Basically the new app should probably be like a child of the old one, basically everything is available from the old one (schedulers, emails, views, routes, migrations, everything), and I can then manually overwrite exactly only the things that I want to change. Now the composer package is a smart idea, but I am not entirely sure how to overwrite stuff. Do i have to create service providers? contracts / facades? – Toskan Jun 11 '17 at 23:13
  • You'd need to build everything as a standalone component, rather than specific for each app. – Stephen RC Jun 12 '17 at 02:56
0

You can use both git alternates and shallow clone features to share objects among repos. This is something github does to save up on storage space when users fork a repo.

Basically the alternates feature gives git a pathname to find objects at. While the shallow clone (can be done locally) gives you a certain amount of the commit history that you specify with the depth option.

Conveniently, git clone can set up the alternates path for you. The command you'll run should look something like this:

git clone -l -s [path to orginal repo]

Note that I did not include the depth option in the command.

Here is the documentation for alternates: https://git-scm.com/docs/gitrepository-layout And here is the documentation for clone: https://git-scm.com/docs/git-clone

Yazeed Sabri
  • 346
  • 3
  • 17
0

Convert the site to multi-tenancy in this case. This allows for completely independent content to be served while operating through the same stack, from the data to the presentation layer. See this package:

https://github.com/HipsterJazzbo/Landlord

This will also save you the headache of managing independent migrations as both sites will use the same db structure.