Unnecessary files in the download installation

[jlamim]

Analyzing the set of files downloaded in one installation via composer and another via manual download I realized that in manual installation there are many unnecessary files, which can end up leaving the user confused.

The following is a list of files and folders that are not part of the system core and could be removed:

• / contributing
• / admin
• /.github
• PULL_REQUEST_TEMPLATE.md
• stale.yaml
• .nojekyll
• Vagrant.dist
• DCO.md
• CHANGELOG.md
• .editorconfig

[fefo-p]

admin files are needed (at least admin/setup.sh) after running composer update

[zahhar]

I would not name this a bug, rather enchancement.

[MGatner]

Some of these files indeed should not be there, this is a bug. The download version also assumes composer is not being used so I think excludes the admin scripts, but will check on that.

[fefo-p]

Though, whoever downloads CI4 will be developing over it, so maybe including a simple text file, stating which files are needed to run vs which are needed to develop, would be helpful.
Just a thought

[MGatner]

I am close to a rework of the release logic and need a verdict on which files go where. @lonnieezell may just want to make that call but this is a good place for community feedback.

---

Here is the current behavior (all repo references are in the codeigniter4/ org):

Manual downloads and AppStarter's vendor directory both contain framework. This repo receives the following from codeigniter4:

app
docs
public
system
writable
contributing.md
env
license.txt
spark
.gitignore
tests/_support
admin/framework/README.md (to root)
admin/framework/composer.json (to root)
admin/framework/phpunit.xml.dist (to root)

AppStarter contains appstarter. This repo receives the following from codeigniter4:

app
public
writable
contributing.md
env
license.txt
spark
tests/_support
admin/starter/.github/workflows/phpunit.yml (to root)
admin/starter/.gitignore (to root)
admin/starter/README.md (to root)
admin/starter/builds (to root)
admin/starter/composer.json (to root)
admin/starter/phpunit.xml.dist (to root)
admin/starter/app/Config/Paths.php (to root)
admin/starter/tests (to root)

Note that there are a few bugs, so the current repos do not necessarily have the intended files.

---

Here are my opinions:

1. No projects should include the User Guide. It duplicates code, bulks up the distributable size significantly, and deters users from using the latest accurate published copy. Downloadable versions will be available from the User Guide's own repo.
2. Likewise, by the time a user has downloaded or installed a code source the decision of intended use should already be made, so no files should be needed within the release itself to differentiate.
3. Manual downloads are designed for users who do not wish to use Composer, so should be free of package-management files and documents whenever possible (note: it is not always possible).
4. Projects downloaded or installed are not intended for development of the framework, so should be free of contribution scripts and documentation
5. All bundled unit tests should use the refactored scaffold and examples

---

I'm here to listen to your ideas.

[MGatner]

Update: see the PR referenced just above this comment for the release refactor. Any review vis-a-vis correct files would be appreciated! You can see example release results at the following repos:

• https://github.com/MGatner/framework
• https://github.com/MGatner/appstarter

[jlamim]

I agree with @MGatner views. I believe that this way the file structure is much leaner.

Another issue that would be interesting to evaluate, and I believe I have already read about it in some other thread is the fact that an installation via Composer has the complete structure (/app, /public ...) inside vendor, and not just the Core of the framework.

The more we dry the file structure, the easier it will be for the user to understand it and to download/install it.

[MGatner]

The duplicate files have come up before but the team is interested in keeping them to make updates to app/ easier. For example, when the Kint Config file was recently added a Composer installation could simply run cp vendor/codeigniter4/framework/app/Config/Kint.php ./app/Config/ instead of having to go download something.

I used to prefer the non-duplicate structure myself but now I’m working on a module to leverage the above fact for automatic project patching.