Naming of project/namespace is not up to convention

arora.shivani → made their first commit to this issue’s fork.

Hello, I have updated the namespace and module naming convention. I have created a patch for it as i am not able to push the code . There is access rights issue.
Please review the patch.
Thank you!

Firstly, if you're still creating patches - please follow patch naming convention:
[issue-number]-[comment-number]-[issue-description].patch
it helps to identify which patch belongs to which issue, and the if it's a latest patch on the issue

Secondly, use git workflow. There's an issue with default branch → but it's easily resolved on your issue branch.

Thirdly, patch doesn't apply.

Moving to Needs work.

VladimirAus → changed the visibility of the branch 3445609-naming-of-projectnamespace to hidden.

Please the update MR.

The namespace used by the module is correct for the module machine name. Usually, one of the modules in a project has the same machine name used from the project containing it, but that is not mandatory. (That is also the case of Drupal core, for which the project machine name is drupal, but none of its modules uses that machine name.)

-name: Cookie Consent Notice by CookieYes
-description: This plugin allows you to add the CookieYes script on overall site from the front-end. No need to open files and add them there.
-package: Cookie Consent Notice by CookieYes
-type: module
-core_version_requirement: ^8 || ^9 || ^10
-configure: cookieyes_scripts.admin.body
-
-# Information added by Drupal.org packaging script on 2023-02-05
-version: '2.0.2'
-project: 'cookie_consent_notice_by_cookieyes'
-datestamp: 1675631189

The cookieyes_scripts.info.yml file in the repository does not contain those lines.

name: Cookie Consent Notice by CookieYes
description: This plugin allows you to add the CookieYes script on overall site from the front-end. No need to open files and add them there.
package: Cookie Consent Notice by CookieYes
type: module
core_version_requirement: ^8 || ^9 || ^10
configure: cookieyes_scripts.admin.body

The patch needs to be created from the repositories, not from the download archive drupal.org makes available.

Namespace for drupal is cookieyes_scripts, however namespace for the composer is cookie_consent_notice_by_cookieyes.

If someone would create cookieyes_scripts module on drupal.org, it would clash with this module hence the comment about namespace.

If somebody would create a module whose machine name is actions_permissions, there would be a conflict with the Actions Permissions module which is part of the Views Bulk Operations (VBO) → project, which is installed with Composer via composer require 'drupal/views_bulk_operations:^4.2'.

For every project with more than a module, the namespace used for Composer is different from the module machine name for at least a module. Given that a project machine name is not required to be equal to the module machine name, that holds true also for projects containing a single module.

What Composer package naming conventions → , linked in the issue summary, says is that the Composer namespace for a project is built prepending drupal/ to the project machine name. It does not say what machine name a module must use and it cannot be used as prove that the module machine name for the module contained in this project is wrong.

So, what's going to happen when someone would create cookieyes_scripts module and then it will clash with this module?

It will happen the same thing that happens if somebody creates a project whose machine name is actions_permissions containing a module with that same machine name.

I tried to create a test site on simplytest.me with this module and another one. The error message I got is the following one.

Unable to install modules cookie_consent_notice_by_cookieyes due to missing
modules cookie_consent_notice_by_cookieyes

While having a module with the same machine name used for the project is not mandatory, the current module machine name does not allow to create a test site on simplytest.me that uses this module.

I would like to fix this, but in a different branch, the same that is compatible with Drupal 11.

I would postpone this to #3447140: Create a branch for Drupal 11 → .

(Creating a merge request for the 3.0.x branch is not possible in this issue, since it was created before the branch.)