What does the project: key in module.info.yml do?

Question

Note: this is not the book module from core.

I inherited a custom module that was not written by me. Its .info.yml contains a project: key which I have never seen ever before.

ps_book.info.yml

name: Book
type: module
description: Provides lesson page structure
package: Pivotal Science
dependencies:

version: '8.x-1.0'
core: '8.x'
project: 'ps_book'

I noticed that when I install the module I get 3 errors in the log.

I did a mouseover, so you can read the full error. The other two are the same except they end in es.po. and fr.po.

In Let Drupal 8 know about your module with an .info.yml file I couldn't find any mention of the project: key.

If I remove the project: 'ps_book' line, I no longer get those 3 errors when I install the module.

Is there any official doc for this key? If not, should someone add it the docs?

Answer 1

The Drupal 8 documentation for the keys to use in a .info.yml file doesn't mention it, but that is the same key documented in Writing module .info files (Drupal 7.x).

project (Discouraged, packaging use only)

Module maintainers should not use this at all. The packaging script on drupal.org will automatically place a string here to identify what project the module came from. This is primarily for the Update status module, so that Drupal installations can monitor versions of installed packages and notify administrators when new versions are available.

Drupal uses its value for building URLs when finding information about the module, or any file related to it. Technically, every Drupal core module could use the value of the project key to build a URL for something related to a module. I take the documentation gives the primary use of that key, since the Update module is present in all the last versions of Drupal.

I guess that, since its usage is discouraged, they don't document it for Drupal 8 to avoid users add it in their .info.yml files. It could help users creating a module that handles new keys in .info.yml files, though.
As for documenting it, I would document it just to avoid a developer creates a module that handles custom keys that conflict with the ones already used from Drupal core. I can understand this is seen as a use case that remotely interest developers, though.