Initial project structure. #1

Crell · 2025-09-06T16:49:07Z

A basic project setup, derived mostly from my personal project setup. Please use "suggests" to add your own name and link to the Working Group section. We can tweak this over time, but I wanted to get something in here so we could start adding code.

I am including PHPStan and PHP-CS-Fixer at strict settings. I went with PHPStan because I know it better than Psalm, and it's more widely used. I went with CS-Fixer because its support for PER-CS is more up to date.

I targeted PHP 8.2 as a baseline somewhat arbitrarily. I think it's reasonable for different attributes to have different required versions. I'm fine with increasing the min version, but I wouldn't go lower than 8.2 as 8.1 goes out of security support at the end of this year anyway.

heiglandreas

Thanks @Crell for starting!

.github/workflows/quality-assurance.yaml

phpstan.neon

jrfnl

Glanced through it, haven't checked everything, but I kind of think this needs some more work....

.gitattributes

.github/workflows/quality-assurance.yaml

composer.json

jrfnl · 2025-09-08T21:04:46Z

phpstan.neon

+    paths:
+        - src
+        - tests
+    ignoreErrors:


IMO, as long as there is no code, there should not be any ignores...

Only add those ignores which are needed, when needed.

I find it very helpful to have certain errors turned off in advance, when I know I'm going to turn them off. It saves me the hassle of having to remember how to do it if I do eventually add code that trips over that rule.

See my comment about storing these in a separate branch to be pulled later when it becomes relevant.

phpunit.xml

jrfnl · 2025-09-08T23:39:54Z

Oh, one more remark which I forgot to add - I'd strongly recommend for the phpunit.xml and phpstan.neon to use the .dist file extension. (and possibly .php-cs-fixer.php, though I don't know if that's possible).

And for the phpunit.xml and phpstan.neon (without .dist) to be added to the .gitignore file.

These projects will automagically pick up on either file and the non-dist file overrules the dist file. In other words: this allows for contributors to locally overload these config files if they want to just try out some settings or if they want to add some dev environment specific setup, which shouldn't be included in the generic project config files.

Crell · 2025-09-08T23:42:27Z

Does anyone actually do that? I never have.

jrfnl · 2025-09-08T23:49:07Z

Yes, I do. Everywhere and all the time.

jrfnl · 2025-09-08T23:57:01Z

In case anyone is wondering, here are some reasons of why I do this:

Project phpunit.xml.dist file containing a code coverage configuration specific for CI (clover), while I want to locally use the HTML output.
Project phpunit.xml.dist file not specifying pathCoverage="true" (and rightfully so as it can be pretty expensive in CI), but I locally do want to check with pathCoverage="true" (more for the branch coverage than for the path coverage, but still).
Project PHPUnit set up allowing for overruling where some dependants come from and setting those paths in the <php><env...> settings in my phpunit.xml file.
Project phpstan.neon.dist file being set to a relatively low "level" (and fixing that is not always easy as it would mean breaking changes for extenders), but I locally want to run against a higher level for any new files I add.
Project phpcs.xml.dist file containing a basic ruleset, while I want to apply a higher standard, but can't add the dependency I'd need to do so as it would conflict with other project requirements (but I can run with those rulesets with my system global PHPCS setup).

Just to give you some idea.

jrfnl · 2025-09-09T00:02:21Z

@Crell Please "unresolve" threads which have gotten replies. Those threads are not resolved (and some others aren't either, but are waiting replies from others). Closing discussions this way dismisses valid concerns.

.github/workflows/quality-assurance.yaml

.gitignore

composer.json

heiglandreas · 2025-09-09T15:12:27Z

Does anyone actually do that? I never have.

I regularily do that.

Regardles of that it is IMO good citizenship.to do it that way. It doesn't hurt the project and it opens possibilities for contributors.

.github/workflows/quality-assurance.yaml

CONTRIBUTING.md

README.md

Co-authored-by: Jaap van Otterdijk <jaap@ijaap.nl>

jrfnl

Yet more feedback.

.github/workflows/quality-assurance.yaml

jrfnl · 2025-09-10T20:39:44Z

.gitignore

+.env
+vendor
+build
+composer.lock


Just thinking - we don't actually need this if we make a small change in the composer.json file (though it doesn't do any harm to leave this line in the .gitignore anyway).

I'd still keep it. And if only to not confuse people to "Why is there no composer.lock file" ... They might have overlooked the lock: false in the composer.json 🙈

.gitattributes

composer.json

SECURITY.md

composer.json

Co-authored-by: Juliette <663378+jrfnl@users.noreply.github.com>

jaapio

I think this is good for a first version, let's merge this and start improvements via new pr's

heiglandreas

Some minor nitpicks that are not at all relevant and can - if we decide upon it - be modified later on.

So from my side this is a Go 🚀

I'll merge so that we can continue with the first actual attribute

heiglandreas · 2025-09-17T05:22:48Z

.php-cs-fixer.php

TBH: I'd rather see us using phpcs instead. Less opinionated and more flexible. But that is something that we can change along the way.

I didn't comment on it as @Crell specifically mentioned above they wanted to use PERCS and PHPCS doesn't yet have a good ruleset for that, but it looks like something is happening there, so 🤞🏻 we may have a PERCS ruleset to use soonish.

I have no strong preference between the two. I am more familiar with php-cs-fixer, so that's what I used. But "can let us apply PER-CS 2" is the main criteria, so whatever gives solid PER-CS support works for me.

composer.json

heiglandreas · 2025-09-17T05:26:35Z

.gitignore

+.env
+vendor
+build
+composer.lock


I'd still keep it. And if only to not confuse people to "Why is there no composer.lock file" ... They might have overlooked the lock: false in the composer.json 🙈

heiglandreas · 2025-09-17T05:32:13Z

CONTRIBUTING.md

+
+- **One pull request per feature** - If you want to do more than one thing, send multiple pull requests.
+
+- **Send coherent history** - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please [squash them](http://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting.


Suggested change

- **Send coherent history** - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please [squash them](http://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting.

- **Send coherent history** - Make sure each individual commit in your pull request is meaningful and atomic. Make sure each commit-message not only explains the **what** but also the **why**!

Commits should be atomic. If there are multiple commits necessary they should be preserved to understand the process. The "Multiple intermediate commits" sounds like there should only be one commit per PR which I would rather not have people to get the impression of. They should use atomic commits and preserve them.

And if we want meaningful commit-messages it is unfair towards the contributor to then squash them into one.

This is inherited all the way from the PHP League template, I think. I've barely looked at it in years. Follow ups to change this part are fine by me, I don't have strong feelings about it, other than we give people good guidance.

README.md

heiglandreas · 2025-09-17T05:37:10Z

README.md

+
+## Working Group
+
+<!-- Add your own name here -->


Suggested change





- [Andreas Heigl](link-heiglandreas)

heiglandreas · 2025-09-17T05:39:20Z

SECURITY.md

Should we include a sentence that this is a volunteer project without funding and that we are not able to pay bug bounties?

We can. As I said, I stole this doc straight from my own template where I don't say that, but maybe should. 😄 Easy follow up for someone.

Initial project structure.

e461709

heiglandreas approved these changes Sep 6, 2025

View reviewed changes

mathroc reviewed Sep 7, 2025

View reviewed changes

.github/workflows/quality-assurance.yaml Outdated Show resolved Hide resolved

phpstan.neon Outdated Show resolved Hide resolved

jrfnl reviewed Sep 8, 2025

View reviewed changes

Crell added 4 commits September 8, 2025 17:54

Revise git-attribute excludes.

3e6a19e

Assorted fixes from review.

59bfc81

Assorted fixes from review.

34f7d61

Use phpstan identifiers.

2f57ad8

Crell commented Sep 9, 2025

View reviewed changes

.github/workflows/quality-assurance.yaml Outdated Show resolved Hide resolved

Crell commented Sep 9, 2025

View reviewed changes

.github/workflows/quality-assurance.yaml Outdated Show resolved Hide resolved

Crell commented Sep 9, 2025

View reviewed changes

.gitignore Outdated Show resolved Hide resolved

Crell commented Sep 9, 2025

View reviewed changes

composer.json Outdated Show resolved Hide resolved

Remove a few more unnecessary bits

eb2bbd9

jaapio reviewed Sep 10, 2025

View reviewed changes

.github/workflows/quality-assurance.yaml Show resolved Hide resolved

CONTRIBUTING.md Outdated Show resolved Hide resolved

README.md Outdated Show resolved Hide resolved

README.md Show resolved Hide resolved

Crell and others added 2 commits September 10, 2025 14:25

Add Jaap

aecfed5

Co-authored-by: Jaap van Otterdijk <jaap@ijaap.nl>

main vs master

246de5b

Co-authored-by: Jaap van Otterdijk <jaap@ijaap.nl>

jrfnl reviewed Sep 10, 2025

View reviewed changes

Crell commented Sep 10, 2025

View reviewed changes

composer.json Outdated Show resolved Hide resolved

Assorted fixes

453afd0

Co-authored-by: Juliette <663378+jrfnl@users.noreply.github.com>

jaapio approved these changes Sep 10, 2025

View reviewed changes

Rename to dist files.

58c04e0

heiglandreas approved these changes Sep 17, 2025

View reviewed changes

heiglandreas merged commit d131700 into php-fig:main Sep 17, 2025


		- One pull request per feature - If you want to do more than one thing, send multiple pull requests.

		- Send coherent history - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please [squash them](http://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting.

	<!-- Add your own name here -->
	<!-- Add your own name here -->
	- [Andreas Heigl](link-heiglandreas)

Initial project structure. #1

Initial project structure. #1

Uh oh!

Conversation

Crell commented Sep 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

heiglandreas left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jrfnl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jrfnl commented Sep 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Crell commented Sep 8, 2025

Uh oh!

jrfnl commented Sep 8, 2025

Uh oh!

jrfnl commented Sep 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jrfnl commented Sep 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

heiglandreas commented Sep 9, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jrfnl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jaapio left a comment

Choose a reason for hiding this comment

Uh oh!

heiglandreas left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Crell commented Sep 6, 2025 •

edited

Loading

jrfnl commented Sep 8, 2025 •

edited

Loading

jrfnl commented Sep 8, 2025 •

edited

Loading

jrfnl commented Sep 9, 2025 •

edited

Loading