Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rule: Check Module file structure #30

Open
larsroettig opened this issue May 13, 2018 · 5 comments
Open

Rule: Check Module file structure #30

larsroettig opened this issue May 13, 2018 · 5 comments
Labels
debate needed non-PHPCS This rule is not feasibly implementable with phpcs, will need additional tools

Comments

@larsroettig
Copy link
Contributor

A typical file structure for a Magento 2 module shoul look like the following:

image

For this reason, we a should add a warning if in main an unexpected dir.

Expected dirs:

  • Api
  • Block
  • Controller
  • Console
  • Cron
  • etc
  • Model
  • Setup
  • i18n
  • Observer
  • Plugin
  • Test
  • view

Dokumentation:

https://devdocs.magento.com/guides/v2.2/extension-dev-guide/build/module-file-structure.html

@fooman
Copy link

fooman commented May 13, 2018

Thanks for bringing this up.

I generally agree that we should check for expected folder structure. I however would like to include a discussion (including with Magento) what this folder structure should be in the first place.

In particular should Magento go its own way (again) or should it follow where PHP as a whole seems to be heading. For example: On structuring PHP projects and php-pds

One issue which I think is currently insufficiently catered for is the question how are tests distributed in a standardised way. The current Test folder covers unit tests but there is no established way on how to for example distribute integration and functional tests (this will be important for the new MFTF tests as well).

@jissereitsma jissereitsma changed the title Check Module file structure Rule: Check Module file structure May 14, 2018
@schmengler
Copy link
Collaborator

In particular should Magento go its own way (again) or should it follow where PHP as a whole seems to be heading. For example: On structuring PHP projects and php-pds

+1 for php-pds. We should not enforce the same standards for extensions as for core modules, those have different needs. Although in an ideal world, we'd have really modular core modules that could follow php-pds as well.

@schmengler
Copy link
Collaborator

@fooman the article also brings up a good point: "group by archetype" vs. "group by feature": Magento still follows the "group by archetype" pattern, just added more archetypes in Magento 2 (e.g. Api, Observer, Plugin). But other than in Magento 1, we are free to arrange our namespaces as we like, without constraints from the framework and I would not blindly follow the core here, which is not even consistent. I'd love to see our own reasonable guidelines for namespacing, though. This will need more discussion

@schmengler
Copy link
Collaborator

And one my favorite topics: framework independent domain code. I'd hate cramming this into Model, and it's not always reasonable to move it into its own repository. If you have a good argument against custom namespaces at the top module level for framework independent code, please let me know.

@schmengler
Copy link
Collaborator

https://devdocs.magento.com/guides/v2.2/extension-dev-guide/build/module-file-structure.html

Even this documentation is remarkably vague:

A typical file structure for a Magento 2 module can look like the following:

Following are some common module directories:

@schmengler schmengler added the non-PHPCS This rule is not feasibly implementable with phpcs, will need additional tools label May 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
debate needed non-PHPCS This rule is not feasibly implementable with phpcs, will need additional tools
Projects
None yet
Development

No branches or pull requests

3 participants