Roadmap 2.0

[jaapio]

Since we are a new team within an existing project I would like to define a new github project with issues and notes to make clear what our focus will be.

Focus of the project

I think it is clear for everyone in the team that we are working on a library that is able to mock a file system. Currently the project has focused on mocking files and directories. Since those are the most important members of a file system. Are there any other features we might want to support? I don't really have an overview of the supported php file system methods within this library.

QA

From my point of view I would like to add a number of tools and checks to make sure we are delivering a stable library.

• code style check, prefer https://github.com/doctrine/coding-standard
• phpstan
• psaml
• compose-require-checker
• infection (mutation testing)

I like to use psaml and phpstan together since they both focus on different types of issues.

I think it is wise to split the test bench into different parts. Currently the unittests and integration tests are kind of mixed in the same directory. Which makes it hard to understand what is actually tested. Personally I would prefer to use phpunit to do the unittesting and use a tool like behat to test on a functional level.

Communication

Currently we only have github issues to communicate with the team. Do we want to start some chat channel? Gitter? Slack?

I would like to hear your additions. So we can get started as a team instead of being a group of developers that do random contributions to the project.

[bizurkur]

I totally agree about adding the tools to ensure extra safety tests. That's basically what I've tried to start doing based on my original comment for things I would do.

I also think adding phing to run the build process is a good idea. It would allow for easily adding multiple build steps (including adding a lint step).

I've never used the Doctrine coding standard before, but if it's based on the Slevomat rules 👍. I think the most important part about adding an official coding standard is that it at least follows PSR-2 (and probably PSR-12, since that'll hopefully be formalized soon).

Unrelated to all of the above, I also wish the directory structure was different. It seems like "src/main/php/org/bovigo/vfs" could drop the extra 5 folders and just be "src/". Then tests could move from inside "src/" to a dedicated "tests/" folder at the based level. Obviously a move like that would require there be no other PRs open that touch src or tests because it would cause crazy conflicts.

[mikey179]

Regarding the directory structure with src/main/php/org/bovigo/vfs: I didn't go further when the switch from PSR-1 to PSR-4 was made because I always thought I'd like to drop the org part of the namespace. With this folder structure it would be easier on the migration path, because if this change would occur there should IMHO be at least one major version which has both.

For the QA tools, I'm fine with whatever you like to use and add. I'm not up to date with what's currently state of the art. (Well, except that I don't like phing that much, but if everyone agrees it's the way to go then so be it.)

Focus: currently the project supports everything that is doable with a PHP stream wrapper. I don't think the focus should be much larger. Once there was the idea of introducing partitions, but I don't think the necessary effort and bc breaks are worth it as I don't think a lot of people would make use of that. Another feature might be support for symlinks, but that requires a change in PHP itself to make that feasible.

[jaapio]

I created a project: https://github.com/orgs/bovigo/projects/1

Please feel free to add new notes. We can discuss them at the team page when needed. I forgot that one in our communication channels.

I do fully agree with @mikey179 that we should not enlarge the scope of the project. Keep the focus on php stream wrapper. Is just the task of this library.

But I think we should still define what we want to do in a v2 version. I think one of the important steps is to bring this project to the latest standards within php. Make it PSR-4 compatible.

future php version support is a must. Support for php 7.3 and 7.4 should be added in v2. If we are able to support php 8 without BC breaks that could be in v2 as well. But that's not a must for me. Since php8 is still miles away.

Personally I don't like phing. It is just another layer of scripting. If it is clearly documented what a contributor should do before creating a PR, I'm happy with travis config and maybe some github actions when they are available for everyone.

[bizurkur]

I also agree about the scope. Keep it simple. Do one thing and do it well.

That's at least two votes not to use phing. I'm not hard-set on using it, so I won't push for it.