3.x: page modules and the `name` option

Thread pulling time. The facts (that you can correct me on):

• As an inherited pattern, in A3 all page types can be referenced as @apostrophecms/page. This is because all pages are a single doc type, even if they’re different page types.
• In 2.x, this same convenience was apostrophe-page.
• In 3.x, there is a module already named @apostrophecms/page, but in 2.x there is not a module called apostrophe-page (it’s apostrophe-pages).
• In 3.x, this pattern is implemented in the doc type module, @apostrophe/any-page-type (in 2.x it was apostrophe-custom-pages)
• To get this all working, any-page-type gets the option, name: '@apostrophecms/page'. Things are already getting confusing…

The problem is appearing as we’re going to remove the name option from doc type modules. It’s rarely used and we can be simpler and more consistent if we use the meta name that most use anyway (self.__meta.name). But because of the convenience covered above, our relationship fields have been using @apostrophecms/page to reference any page. This is complicating removing that option and causing errors.

• Option 1: We use @apostrophecms/any-page-type to reference all pages instead. The most significant context would probably be in relationship fields. It’s new and thus scary, but is it bad?
• Option 2: We use another name altogether. I don’t know what.
• Option 3: We continue to use @apostrophecms/page and figure out how to rig up any-page-type to work without the name option. The biggest argument in favor of this is that all the REST API routes use this “name” as well, so all page stuff uses the same term. It does seem… weird… and maybe bad that we’re using the name of a related-but-different module as the “name” of another module.

[stuartromanek]

Sure, it’s sort of a strange meta name but not unreasonable or bad, and not seemingly wrong when encountered first in documentation, I’d think

[abea]

Correct. Probably go with the piece manager option since in that context you don’t really care (?) about the page tree. But that’s a problem for another day. The answer for now might be that “any-page-type” is okay since One Day we’ll be able to join to specific page types selectively.