Best Practices: Sharing a project

Hi all- I'd like to hear some opinions and feedback on a common distribution scenario, and any expertise others might have from other frameworks or projects. Here's the scenario:

I write an app using CodeIgniter 4, post it to GitHub, it gets popular, 2000 users clone the repo, configure and run their own version of the app. They want to stay fresh with the latest-and-greatest so whenever I update the repo they merge it into their project. Well along comes some changes in app/Config/ affecting files that they have modified to run their instance (e.g. Email config, constants re-definitions, update to a third-party module config file...) and now they have a conflict.

Are downstream users of framework apps destined to handle changes by hand? I put whatever I can into environment files or the database to curb some of this, but that isn't always an option. Thoughts?

If they modify the files themselves there is not much that you can do about it.

A solution might be to have a config just for updates and not allow them to modify it.
Your core would need to handle the custom configuration file.

Out side of that the users would need to update all their changed files manually.

What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )

Hmm yeah an external config is not a bad idea. I've been wondering about pre-defining an empty module, something like a "local" directory in the root of the project and then add it to app/Config/Autoload.php under the "Local" namespace. I could ship it empty but have instructions to apply config values in there with a fallback in app/

An update module like you mention sounds like a good idea.

What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )

Depending on what type of configuration you need to save. It can be done in the database itself (if the app are database driven).
Or save a file during configuration/initial setup. Most apps that I download requires you to copy the sample Configuration file, and make it your own. And therefor it will not be overwritten. But they will not get the latest goodies (in terms of new configurations). That conflict will they need to solve on their own.

You should of course hint in the changelog and/or upgrade guide on new configurations options so they can copy those over. Personally I make this file read-only so it can't be overwritten, so I don't appreciate someone trying to auto-patch it.

I would also include CI4 with Composer, the framework itself. So that they can (if/when) you abandon said project. Always be able to download the latest CI version instead of downloading a zip and patch it manually. "Adding CodeIgniter4 to an Existing Project". It will also slim your project down. If you have a specific version in mind. Specify it in your Composer.json instead.

Could .env file be modified to indicate there are changes to ./appConfig

Good ideas, both of you! I’m afraid the issue is larger than that, as it includes third-party modules that need configuring. For example, I’m using Lonnie’s Myth:Auth and will include instructions on how to configure the Activator emails BUT I also want to preconfigure some other values in app/Config/Auth.php. https://github.com/lonnieezell/myth-auth...h.php#L211

I really like this idea of an empty namespace that ships with projects and can receive “overrides” without removing files from the update stream. I think it would take extending the core Config class to prioritize that namespace.

You should definitely override default configuration from one global user configuration file. If you are going to ship a complete application. User's won't be bothered setting it up in multiple locations.

Hello ! I don't know what kind of changes are planned in "app/Config/" files, but I am afraid to change things in this directory. Simple examples: I have custom routes, custom classes loaded with "autoload", custom config variables in "App.php" like "$supportedThemes" / "$defaultTheme" (dark/light) or "$supportedUnitsSystems" / "$defaultUnitsSystem" (imperial/metric)... Conclusion ? I am "afraid" to update my app now :-D

All apps are not using a database (I created a Slack bot with CI4 for instance), and I don't want to create ini/json (or whatever) files to store app settings (that is what I do sometimes) when there is a "config" folder with many options... If these files and options cannot be used because updates will (potentially) overwrite them, then maybe it shouldn't be in the "app" folder but rather in the "system" dir (or anywhere else).

This thread is interesting. I would like to know how people are managing this, and hear some recommendations.

Hey ! I was looking for something totally different, but I found your plugin @MGatner: https://github.com/tattersoftware/codeigniter4-settings

It looks like your first thought was to save settings in the database (your plugin), and to use the env file too (this thread). But it isn't a solution in my case as:
1/ I don't always have a database as I said.
2/ With the env file/config folder, I am in the same situation as you...

It seems like the only solution for me right now is to create my own files elsewhere to store settings...

FYI, in the Slack bot I have created, i store things like API tokens (prod + dev), UserID, bot name, etc... This is a single user application. Settings are app settings, not user preferences. But the user should still be able to modify this from his frontend interface. There is no need for a database, these are the only info to store. In this case, to me, the config folder has no more interest and shouldn't be in the app folder. These are not my settings, it is just here because... CI requires it (?).