Uploaded image for project: 'Magnolia'
  1. Magnolia
  2. MAGNOLIA-8916

Blocks/Apps/Workspaces/APIs should be isolated by light module

    XMLWordPrintable

Details

    • Improvement
    • Resolution: Unresolved
    • Neutral
    • None
    • 6.2.32
    • None
    • None

    Description

      In a project with a single light module, the blocks and apps can be easily organized because naming and linking to them relies solely on the file name. But in a project with multiple light modules and different teams maintaining those light modules, blocks/apps/workspaces/APIs need to be uniquely named or collisions happen. Additionally, names have a limit based on what database is implemented. In these projects - as new teams are added - team prefixes or suffixes are defined and name length must be enforced resulting in sometimes cryptic but always unique names for everything.

      This seems like an oversight because:

      1. by default, most teams will never have the latest codebases for the other light modules
      2. teams technically don't need the others locally as they are separate projects
      3. teams won't know of the blocks/apps available to them from these other codebases without exploring them
      4. every light module file structure becomes loaded with prefixed/suffixed filenames
        1. complicating visually scanning or searching the codebase
        2. decreasing the readability of PRs
        3. adding a tax on the team members for sharing a hosting environment
      5. parts of templates - like dialogs - already work with a limit like this today

      As developers, it can be shocking to add blocks to your app, only to have them be blocks from another light module once in a testing environment. Or to have your app names work in H2 but take a server offline in Postgres. Or to have to remember some special project naming convention when you work on multiple projects.

      It's a complexity that puts what I feel is undue effort on development teams in these shared environments just because they all want a slightly different block called header or video or an app/workspace called articles. With all that is defined in light modules today, it would really simplify everything from development patterns to filenames if there was some light module level feature that put some barriers between these things unless specified as another light module in yaml.

      Can there be some sort of automatic limiting by light module boundaries? Something like dialogs field in template definitions or maybe full file paths like an include if expecting to use features of another light module? Possibly a light module level config option for an automatic prefix/suffix on all features of the light module?

      Checklists

        Acceptance criteria

        Attachments

          Activity

            People

              Unassigned Unassigned
              caksamit Chuck Aksamit
              Chuck Aksamit
              Nucleus
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:

                Checklists

                  Task DoD