[MAGNOLIA-8916] Blocks/Apps/Workspaces/APIs should be isolated by light module Created: 24/May/23 Updated: 30/May/23 |
|
| Status: | Open |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | 6.2.32 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Chuck Aksamit | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Template: |
|
||||
| Acceptance criteria: |
Empty
|
||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||
| Date of First Response: | |||||
| Visible to: |
Chuck Aksamit
|
||||
| Team: | |||||
| 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:
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? |