Multiple "Entity Group" choices in Laravel Jetstream other than Teams & Members

[andrewdwallo]

I was going to make a Pull Request to the current version of Jetstream (2.x), but before I did I reached out to the Laravel discord to ask what I should do because the pull request I am thinking of submitting contains a very large feature (and many small ones) that does implement many new Folders and Files into the Jetstream Package git repo... but surprisingly... does not currently break any changes.

Currently, when using/installing Jetstream into an application/project a person is allowed to choose what options and features they want to implement into their project that Jetstream currently supports. As of right now, one of the most used features (if I had to guess) would be the "Teams" option whenever someone installs Jetstream. As many of you already know... by default every user has a personal team, the owner of this team can invite "members" to their team, these members can have "memberships", and the owner can manage these members. Jetstream does really well with this setup and one day I was thinking, it would be nice If I can change the "entity group" to "Companies" instead of "Teams", and perhaps change "Members" to "Employees" where these "Employees" I suppose have an "Employeeship". This is just an example... but, essentially all of Jetstream's functionality/logic isn't specific to a certain group of entities,... only the naming of them is. If you actually thought about it there are many "entity groups" that share a common/similar function to that of a Team...

The current PR I am thinking of submitting essentially gives someone the option to choose from multiple "entity groups" that they can implement into their project. I thought this might be a cool feature to implement because... maybe perhaps someone's project doesn't deal with teams but maybe some other group type. Only having the option of using "Teams" could break someone's decision to install Jetstream considering all of its routes, namespaces, paths, etc.. are using the same name.

If you are thinking this is an easy fix after installing the application I would probably disagree considering almost every namespace of a file down to the root of Jetstream's core files contains either the word "Team" or "Teams", and in every single one of these files the word shows up "A LOT"... But with my PR the entire core package of Jetstream is more "modular" to where everything is separated by their "group entity" or if they did not opt for a group entity they will be installing (per usual) the base Jetstream installation files... of either the regular Livewire or Inertia setup,.. AND with my PR a person can even install multiple "group entities" without breaking anything and with no errors... and they can even "switch out" ones they did not "want" or "like" without errors... ALSO another bonus/feature that could take place with this if further implemented is that Jetstream can even give someone the option to choose from a template that they can personalize considering all "group entity" view files are inside of their own directory folder. There is actually much more than this but this is just the Gist of the main feature of the PR I am thinking of submitting.

Edit: Also I wanted to note everything mentioned here already works with the current release but it is one of many major features I want to implement but my original mindset was to implement something that wouldn't break changes and would work when installing Jetstream's current release (of course), but while working and developing my branch, and thoroughly reading through every file Jetstream has in their package,... many ideas came to mind that could be GAME CHANGING, but... these ideas would break changes in the current release...

I would understand if Laravel did not want to implement something like this into their package considering it does make a huge change and it is a huge commitment, but I would still like to offer the branch if possible for people to have the choice to choose...
That is all, thank you if you stayed to read all of this and let me know of your opinions!

[Sophist-UK]

You would probably be better off (if you can) doing this as an add in extension. This appears to be the way that the Laravel ecosystem operates, and you will be in control of the publication of your work rather than put in a lot of effort only to find that Taylor won't merge it (because he believes it is not core enough and should be an extension).

[andrewdwallo]

How would I make an "add in extension"? are you talking about just making my own plugin?