General Considerations

[DavidBruchmann]

Currently I've the impression, excuse if I'm wrong, the whole solution is somehow monolith and decisions to add this or remove that are made once and for all.
This shouldn't be the case, it was ok when extbase was relatively new and people had to learn how it works, and how extensions have to be built in general.

Some decisions I've in mind, and that left somehow -- at least some thoughts:

• removal of the test folder, including all test files
• the change from plugin based on field list_type to one based on CType

I think those things should be configurable and optional available.

Furthermore I've the impression that the whole classes rely strongly on the implemented view logic, and the switch from one JS-framework to another one has impact on almost everything.
Instead I'd prefer an agnostic core API and the view is built around it. Like this theoretically even different views would be possible, i.e. one like that of sav_library_kickstarter.

I know concerning the update to v12 I'm coming quite late with my thoughts, but I didn't have the ideas before.

[DavidBruchmann]

Some ideas about details:

• selector about database relations with help of images / screenshots, also including the "group" option that allows page and table independent connections.
• selection if a plugin shall work with extbase or differently (core-API or TypoScript only).
• selection about a plugin's main type (CType or list_type), and if list_type shall be offered for those of type CType for sub-options (imagine a container element where you can switch between tab and accordion display).
• the option to include tests (PhpUnit).
• the option to include linters for PHP and TypoScript.
• option to include actions for github / gitlab / bitbucket for the tests and linters.