Fix github action "Split Packages" on forks.

[netzknecht]

After some trouble with the first version #1276 — it was quite late yesterday 😴 — now the second pull request with the expected result.

This commit adds variables for packages and repository mapping inside .github/workflows/split_packages.yml, to allow selective package splitting on a forked monorepo, with deviating repository names.

Available variables:

• SPLIT_PACKAGES
  info: Defines the lunar packages to split into a separate repository from the monorepo.
  type: JSON array literal as string
  default: '["admin", "core", "licensing"]'

• SPLIT_PACKAGES_REPOSITORIES
  info: Allows to map a lunar package to a specific repository by key/value assignment: {"package": "repository"}. If not given, the package name will be used.
  type: JSON object literal as string
  default: '{}'

• SPLIT_UTILS
  info: Defines the utility packages to split into a separate repository from the monorepo.
  type: JSON array literal as string
  default: '["livewire-tables", "scout-database-engine"]'

• SPLIT_UTILS_REPOSITORIES
  info: Allows to map a utility package to a specific repository by key/value assignment: {"package": "repository"}. If not given, the package name will be used.
  type: JSON object literal as string
  default: '{}'

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
lunar-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 28, 2023 10:46am

[alecritson]

Hi @netzknecht Can you give a bit of an explanation to the reasoning behind this PR? How does it benefit other developers who use the package?

[netzknecht]

I'm working on a project that only uses the lunar core package via compser require lunarphp/core, that works so far pretty well. But if I do my contributions or maybe customizations on the forked monorepo, like the contribution guidelines say, I need a way to split the monorepo or only use the core package from there.

For local development alone or in very small teams it is possible and sufficient enough to clone the forked monorepo into ./packages/lunarphp-lunar and using a symlink ./packages/lunarphp-core to ./packages/lunarphp-lunar/packages/core.

But in larger teams where only few people are involved in contribution on lunarphp and the other team members should only use the lunarphp composer package, it is nice to have a "private" composer repository like private packagist or satis therefor. The composer repository generates a package e.g. lunarphp-core from a defined git repository, where the splitted monorepo is required.

Another approach to define the git repository as composer repository doesn't work for me because of naming conflicts and the monorepo concept.

[netzknecht]

And because terms like "core" and "admin" are very unspecified for the name of a forked repository, it is helpful to allow the mapping of packages to the relating repositories with other names like "lunarphp-core" for example.

But the main issue of this commit was the hard coded "repository_organization", everything else is a benefit on top.

As well as the ability to define which packages should be separated or not.

[wychoong]

Not really understand what is this trying to solve as I have forked the monorepo and symlinked ./packages/lunarphp-lunar and able to just use the core without the hub

[netzknecht]

If you don't need the hub/admin backend for a project, because you just want to connect an existing ERP e.g. via an API to lunarphp core and build a frontend. But you have to be able to contribute to the monorepo.

[netzknecht]

For local development alone or in very small teams it is possible and sufficient enough to clone the forked monorepo into ./packages/lunarphp-lunar and using a symlink ./packages/lunarphp-core to ./packages/lunarphp-lunar/packages/core.

Also, it's possible to to add the subfolder ./packages/lunarphp-lunar/packages from the monorepo as composer repository to be able to only install the core package:

"repositories": [ 
    { "type": "path", "url": "packages/lunarphp-lunar/packages/*", "symlink": true },
    { "type": "path", "url": "packages/*", "symlink": true },
],

[wychoong]

For local development alone or in very small teams it is possible and sufficient enough to clone the forked monorepo into ./packages/lunarphp-lunar and using a symlink ./packages/lunarphp-core to ./packages/lunarphp-lunar/packages/core.

Also, it's possible to to add the subfolder ./packages/lunarphp-lunar/packages from the monorepo as composer repository to be able to only install the core package:

"repositories": [ 
    { "type": "path", "url": "packages/lunarphp-lunar/packages/*", "symlink": true },
    { "type": "path", "url": "packages/*", "symlink": true },
],

correct. this is my setup

# removed some lines for sanity
wychoong@WY-MBP lunar-ecomm % ll packages/lunar/.
-rw-r--r--   1 wychoong  admin    2032 Aug  8 00:42 README.md
-rw-r--r--   1 wychoong  admin    2848 Sep  8 18:04 composer.json
-rw-r--r--@  1 wychoong  admin  381226 Jul 28 01:43 composer.lock
drwxr-xr-x@ 10 wychoong  admin     320 Aug  8 00:54 docs
-rw-r--r--@  1 wychoong  admin    2028 Dec 30  2022 monorepo-builder.php
drwxr-xr-x@  4 wychoong  admin     128 Sep  8 18:04 packages
drwxr-xr-x  55 wychoong  admin    1760 Jul 28 01:43 vendor
wychoong@WY-MBP lunar-ecomm % ll -t packages     
lrwxr-xr-x  1 wychoong  admin  11 Sep 13 00:10 lunar -> ../../lunar

in composer

 "repositories": [
        {
            "type": "path",
            "url": "packages/*",
            "symlink": true
        }
    ],
    "require": {
        "php": "^8.1",
        "laravel/framework": "^10.0",
        "laravel/sanctum": "^3.2",
        "laravel/socialite": "^5.5",
        "laravel/tinker": "^2.7",
        "league/flysystem-aws-s3-v3": "^3.0",
        "lunarphp/core": "dev-main",

i can still work use it and contribute. so I'm not sure how this PR makes it possible or how is it not possible without

[netzknecht]

This approach works for local development but if other environments (testing/staging/live) or e.g. frontend developers are involved and you need custom changes or something relevant isn't merged to the upstream, it is more comfortable to only use composer to resolve dependencies and not to clone/pull changes or switch version via git inside the ./packages folder to. It is good for local development but not for package distribution.

[glennjacobs]

This isn't something I want to be changing. I would suggest following @wychoong 's approach.