489
233
31
PHPStan based SQL static analysis and type inference for the database access layer
cs2pr - Annotate a GitHub Pull Request based on a Checkstyle XML-report within your GitHub Action
Analyzes PHPStan baseline files and creates aggregated error trend-reports
Events
`mb_detect_encoding()` detects UTF-8 emoji byte sequence as ISO-8859-1 since PHP 8.1
giving UTF8 per se a bonus might work today, but maybe a new charset will come up in the future which will take the lead and changing a implicit charset which gets a bonus (and decide at which point in time when this decision is made) is a big BC break.
I am also open to giving a 'bonus' to the first candidate encoding in the provided array
I think this makes more sense, as the consumer of the api is in control and can take better decisions then php alone for the whole ecosystem
use-case beschreibung
Feature description / Feature Beschreibung kurz beschreibung was die use-cases tun und was das ziel ist des use-cases
blockierenden loader verwenden nach use-case wahl
Feature description / Feature Beschreibung damit der user merkt dass man nach wahl des use-case warten muss, weil der prozess bereits läuft
Type coverage erklären
Feature description / Feature Beschreibung
Die Qualität der refacotrings ist abhängig von nativem type coverage, was mit rexstan messbar ist.
Diesen Zusammenhang erklären
bc break preserving
My idea is more about developer experience as a whole, for the very first steps one needs to take to get higher type coverage in component projects where you cannot change public symbols because this would need changes in consuming projects.
Its not about enabling feature switches on a per rule basis but similar to e.g. php target version, where one defines globally for multiple rectors that they should not touch code which might break consuming code (as a safety step to increase type coverage in the first place, without manual intervention)
UI aufhübschen
Ok. Gib am besten bescheid sobald du anfangen willst/kannst
UI aufhübschen
PS: damit wir uns nicht gegenseitig in die füße schießen würd ich erstmal jetzt mit der entwicklung warten bis du das UI gemacht hast
onboarding
Feature description / Feature Beschreibung den prozess des addons/das vorgehen wie man es bedienen sollte skizzieren/erklären
UI aufhübschen
@skerbis ich hatte überlegt ob man ggf. im 1. wizzard step die core-packages komplett ausblendet, da diese in der regel im redaxo core mit anderen tools bearbeitet werden und daher eigentlich für die "normalen" user nur die UI unnötig aufblasen.
meinung von dir dazu?
am ende der migration fürs gleiche addon den nächsten use-case wählbar machen
Feature description / Feature Beschreibung
also zusätzlich zu "nächste migration starten" ein 2. button, der die addon auswahl beibehält und direkt bei schritt 2 einsteigt
sollte `treatPhpDocTypesAsCertain: false` entfernt werden?
Feature description / Feature Beschreibung
https://github.com/FriendsOfREDAXO/rexstan/blob/4730aa0c4bb78de54e9bb7f598c5b012eadb0e6d/default-config.neon#L72
see https://github.com/phpstan/phpstan/discussions/9094
this leads to false positives, but also allows us to detect some errors, which are ignored otherwise. I don't like the false positives but not detecting obvious errors is even worse
implement reportUnmatchedIgnoredErrors setting
Todo: mark rexstan native ignore rules as reportUnmatched: false
fix package name
Merge pull request #4 from FriendsOfREDAXO/fix
fix package name
Merge branch 'main' into github
Create .github/FUNDING.yml (#27)
prepare next release
Create .github/FUNDING.yml (#27)
