Extending events widget and using addFields breaks max limit fields

[abea]

Having an addFields property in a module extending apos-events-widgets seems to break the limitByAll and limitByTag fields.

  label: 'Events',
  addFields: [
    {
      name: 'link',
      label: 'Link',
      type: 'singleton',
      widgetType: 'link'
    }
  ]
};

I'm getting some of the handy new warnings:

⚠️  widget type events, field name by:

showFields for the choice all includes limitByAll, a field that does not exist in the schema


⚠️  widget type events, field name by:

showFields for the choice tag includes limitByTag, a field that does not exist in the schema

Maybe worth double checking apos-blog?

[boutell]

I can't reproduce this in apostrophe-open-museum. At no point did I see the behavior you're describing, nor does it make sense to me still as I look over the code. apostrophe-events-widgets has no addFields, and apostrophe-pieces-widgets plays the beforeConstruct game properly. However, I encountered some weirdness in my attempt to reproduce the issue: * That project extends apostrophe-events as "events" and sets the alias "events" for that module. * This works, as far as that module goes - it can find apostrophe-events as a base class - but, apparently if apostrophe-events is not configured directly the other modules in that bundle do not become visible as possible base classes. 😭 This is probably why @stuartromanek punted and extended `apostrophe-pieces-pages` and `apostrophe-pieces-widgets` instead. * So I tried configuring apostrophe-events, which allowed me to extend apostrophe-events-pages and apostrophe-events-widgets. But, apostrophe-events is camping on the "events" alias so I get a conflict with the project-level "events" module and a hard fail when I try to have both. 👺That's against the rules. npm modules are never supposed to hardcode an alias. But if I try to fix it now it'll break somebody's project. 👺👺 * Still, I don't actually want apostrophe-events to be instantiated and I don't want it to be in the admin bar, separate from "events." So I added "instantiate: false" to the config for apostrophe-events. This worked: I can do all the things, extending apostrophe-events-pages and apostrophe-events-widgets, and nothing appears to go wrong with addFields which Stuart was already using here. I think the alias thing would not really matter in practice if we fixed it so you can extend modules in a bundle as long as you're at least extending the root module of the bundle. That would meet reasonable expectations. I opened #1833 to track it. Still can't reproduce the original bug though, so I'm closing this ticket, but feel free to reopen with a link to a project / branch that duplicates it.

…

On Thu, Feb 28, 2019 at 3:45 PM Alex Bea ***@***.***> wrote: Having an addFields property in a module extending apos-events seems to break the limitByAll and limitByTag fields. label: 'Events', addFields: [ { name: 'link', label: 'Link', type: 'singleton', widgetType: 'link' } ] }; I'm getting some of the handy new warnings: ⚠️ widget type events, field name by: showFields for the choice all includes limitByAll, a field that does not exist in the schema ⚠️ widget type events, field name by: showFields for the choice tag includes limitByTag, a field that does not exist in the schema Maybe worth double checking apos-blog <https://github.com/apostrophecms/apostrophe-blog/blob/master/lib/modules/apostrophe-blog-widgets/index.js> ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#38>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB9fdQsmWeE7ntqRQxasyOnHJk0GtJpks5vSD_agaJpZM4bXsxu> .

-- *Thomas Boutell, Chief Software Architect* P'unk Avenue | (215) 755-1330 | punkave.com

[boutell]

Well I won't close it yet... please do link me up to a reproduction of the issue.