Laravel 11 Support for Lunar v1 (Clean Install)

[adam-code-labx]

This PR gets Lunar v1 up and running with Laravel 11 🚀

I've forked and updated the following repositories:

• marvinosswald/filament-input-select-affix
• leandrocfe/filament-apex-charts
• cartalyst/converter
• kalnoy/nestedset

For Lunar v1 users to benefit from these updates, they will need to add these repositories to their project's composer.json

"repositories": [
    {
        "type": "vcs",
        "url": "https://github.com/adam-code-labx/filament-input-select-affix"
    },
    {
        "type": "vcs",
        "url": "https://github.com/adam-code-labx/filament-apex-charts"
    },
    {
        "type": "vcs",
        "url": "https://github.com/adam-code-labx/converter"
    },
    {
        "type": "vcs",
        "url": "https://github.com/adam-code-labx/laravel-nestedset"
    }
]

My next step will be to submit PRs to these repositories, ensuring that everyone can benefit from Laravel 11 compatibility.
Then of course the above repositories will no longer be required.

I've put it through tests on both Laravel 10 and 11 everything passes, updated spatie-media and its enum fill for conversions, tweaked the docs for early opt-in support, and fixed up the spatie permissions migration.

Also adjusted the GitHub workflow to support Laravel 11 testing.

[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	Mar 28, 2024 11:06pm

[adam-code-labx]

Not quite sure how to configure your test matrix workflows so will leave this to you guys.
everything is passing locally

Sent minimal PR's to the 2 filament packages.

These 2 however already have Laravel 11 Shift PR's pending

• cartalyst/converter
• kalnoy/nestedset

[adevade]

@adam-code-labx Nice work, man! 👍

[wychoong]

one of the annoying upgrade to v11 is in the migration where ->change doesn't retain existing attributes https://laravel.com/docs/11.x/upgrade#modifying-columns

was this being considered in this PR?

[glennjacobs]

Should we not be considering Laravel Shift for this? I'm concerned we may have missed important updates here.

[adam-code-labx]

one of the annoying upgrade to v11 is in the migration where ->change doesn't retain existing attributes https://laravel.com/docs/11.x/upgrade#modifying-columns

was this being considered in this PR?

This is currently a draft PR. I will be working further on this today so will make sure I go through the upgrade guide carefully.

@glennjacobs Sure we could try to run Laravel Shift to upgrade to Laravel 11 but I feel this is targeted more for simpler projects, this would certainly suggest using multiple version constraints for different packages. The manual approach imo seems the best option.

I am not sure if Shift will even modify the github test workflows?

[adam-code-labx]

Reverted test workflows for now.
Dan always makes it look easy: https://github.com/filamentphp/filament/blob/3.x/.github/workflows/tests.yml
Perhaps this is just an issue with orchestra/testbench 🤔

[adam-code-labx]

Just updated deps
Error: Could not authenticate against github.com

I assume this means shifts must be private 😲
Strange it looks public to me! https://github.com/laravel-shift/converter/tree/l11-compatibility 😂

[adam-code-labx]

Can I suggest as v1 is currently in the early alpha stage migrations are simplified merging all the update/add/remove migrations into the create migrations. Then the new lunar upgrade command would perhaps run upgrade migrations from it's own directory. Then we don't even need to worry at this stage about L11 retain existing attributes.

This seems like the best approach for a clean install.
What do you guys think? @wychoong @glennjacobs

[adam-code-labx]

I will start the upgrade PR next weekend. This should give you guys plenty of time to review this PR 1st.
@glennjacobs @alecritson Let me know if anything else needs to be done on this one.

Thanks have a great weekend 👍

[adam-code-labx]

Both my filament package PR's have now been accepted so we only have 2 dependencies pending L11 update.

Here are my suggestions for these 2 remaining packages:
cartalyst/converter can be replaced with are own internal converters for each unit of measurement
which we could place for example here packages/core/src/Base/UnitConverters

For the exchange rates we should use laravel-exchange-rates
Ash has already upgraded this to Laravel 11

kalnoy/nestedset I believe this one is used with the Collection model.
With this package under MIT licence and relatively small package we could simply add the NodeTrait and other classes for example here packages/admin/src/Support/Nestedset

Let me know your thoughts on this @glennjacobs, if your ok with my suggestions I will add this to next weekend todos 😉

[adam-code-labx]

Hi @glennjacobs
Can we please add this one to the roadmap?
https://github.com/orgs/lunarphp/projects/8/views/8

Any idea when you can review this?
My plan was to work on the upgrade PR this weekend once this one was completed.
Thanks.

[glennjacobs]

Hi @glennjacobs Can we please add this one to the roadmap? https://github.com/orgs/lunarphp/projects/8/views/8

Any idea when you can review this? My plan was to work on the upgrade PR this weekend once this one was completed. Thanks.

When all the packages are updated, then we can review this. I think there's one left from what I can see?

[adam-code-labx]

Hi @glennjacobs Can we please add this one to the roadmap? https://github.com/orgs/lunarphp/projects/8/views/8
Any idea when you can review this? My plan was to work on the upgrade PR this weekend once this one was completed. Thanks.

When all the packages are updated, then we can review this. I think there's one left from what I can see?

Yep one left but tbh I think we can replace this with our own internal measurement converters. (Cartalyst doesn’t seem to be actively maintained 1 year since there last commit)

“cartalyst/converter can be replaced with are own internal converters for each unit of measurement
which we could place for example here packages/core/src/Base/UnitConverters”

[glennjacobs]

Hi @glennjacobs Can we please add this one to the roadmap? https://github.com/orgs/lunarphp/projects/8/views/8
Any idea when you can review this? My plan was to work on the upgrade PR this weekend once this one was completed. Thanks.

When all the packages are updated, then we can review this. I think there's one left from what I can see?

Yep one left but tbh I think we can replace this with our own internal measurement converters. (Cartalyst doesn’t seem to be actively maintained 1 year since there last commit)

“cartalyst/converter can be replaced with are own internal converters for each unit of measurement which we could place for example here packages/core/src/Base/UnitConverters”

That could work, as UOM conversions are never going to change :)

[adam-code-labx]

I will try to find some time this week.
@glennjacobs would you prefer the converters to be a separate PR or just push the changes here?

[glennjacobs]

I will try to find some time this week. @glennjacobs would you prefer the converters to be a separate PR or just push the changes here?

Might be easier to check a separate PR, thanks.

[adam-code-labx]

Thanks @wychoong cartalyst updated their package now to support L11
cartalyst/converter#32 (comment)

I still believe it will be better to create are own implementation, however right now we can at least move forward with this PR.

[glennjacobs]

This isn't a true release. We will need either 6.0.4 or 7.0.0 tagged.

[adam-code-labx]

Unfortunately this was never tagged just updated in their dev branch lazychaser/laravel-nestedset#598 (comment)

[glennjacobs]

They will tag it eventually.

[adam-code-labx]

At least we are not using a forked branch anymore. Also as lunar v1 is still in alpha, I would not delay this based on using their dev branch when we can simply provide a patch update once they finally get round to tagging their release 👀

[glennjacobs]

I don't mind doing that as long as we create an issue so we don't forget :)

[adam-code-labx]

@glennjacobs How about we trim down this PR and just focus only on the Laravel 11 upgrade so this can be released perhaps with 1.0.0-alpha.9 this week?

We can save all migration-related modifications for the Lunar install which I can then go ahead and start a draft PR if this works for you?

[glennjacobs]

@glennjacobs How about we trim down this PR and just focus only on the Laravel 11 upgrade so this can be released perhaps with 1.0.0-alpha.9 this week?

We can save all migration-related modifications for the Lunar install which I can then go ahead and start a draft PR if this works for you?

Yes I agree.

[adam-code-labx]

@glennjacobs Sure will get on to this tonight and start the PR for the Lunar install.

Thinking we can use Laravel prompts something similar to my new RESTPresenter package 😜
https://github.com/xtend-packages/rest-presenter/blob/main/src/Commands/RESTPresenterSetupCommand.php

[adam-code-labx]

@glennjacobs Restoring the migrations resulted in all tests failing.

Let's keep this PR targeted only for clean installs, focused on updating workflows and test cases, while also ensuring we have cleaned up the migrations to leave us only with create tables, previous updated migrations have now been merged.

The next PR for the lunar-install will handle the upgrade process. However this one might not be straight forward and will certainly take time to get right, this really shouldn't delay L11 support.

We just to need to make sure everyone is aware that this is currently for clean installs and updating from previous v1 alpha and not currently supported to be used when upgrading from 0.x.

Perhaps as previously suggested this could be released and tagged to another branch.
for example "lunarphp/lunar": "feature/laravel-11"

[glennjacobs]

@adam-code-labx many thanks for all your efforts. I reviewed the PR and decided it would be quicker for me to start on a clean branch to get this done, taking influence from your updates.

The new PR can be found here #1685

The migrations and upgrade command can be discussed on #1382 to determine how we want to move forward.