evaluation of extracting interfaces from application logic

[samuelstroschein]

Context

We should version interfaces like data structures and APIs separately from application logic to decrease the impact of breaking changes on the ecosystem.

Goal of investigation

1. How could a separation be structured?
2. Is a restructuring worth it?

[samuelstroschein]

findings so far

• unbundling of core was triggered by semver for data structures
• Separating data structures from logic leads to (correct) bundling of logic code in SDK. hence, we have come close to full circle

[samuelstroschein]

Is one package can have mutliple items really valuable?

Cons:

• requires concept of "package" instead of simply "install a lint rule or a plugin"
• increases resolution complexity
• best-practice of "one package should do only one thing" is not obeyed, leading to bloated packages
• requires the concept of project.disabled because one package can contain multiple lint rules
• conflicting package with module definition. documentation mentions "packages are ES modules under the hood" eeergggh why not module then?
• marketplace requires resolution logic and making a plugin manifest or lint rule manifest is impossible because top level package manifest is required.

Pros:

• developers can write one package/module that can contain multiple lint rules or plugins

Review

The pros are not worth the cons!

Proposal

• remove the possibility for one package to define multiple lint rules or plugins

Writing a plugin or lint rule already contains the information via meta.id if the item is a lint rule or plugin, no need for a plugins: [ ] export. Also, look how simple a plugin now becomes:

export default myPlugin

export default myLintRule

• rename projectConfig.packages to projectConfig.modules because packages doesn't exist anymore and defacto modules are imported
• remove projectConfig.disabled because redundant

[samuelstroschein]

@floriandwt sorry :D removing packages alltogether makes most sense. I had the feeling yesterday on the call but now I have gewissheit

[samuelstroschein]

Proposal: Split lint-rule into message-lint-rule and future lint-rule

The refactor prepared for additional lint rules which complicates types and logic with the assumption that message and upcoming lint rules share logic. In reality, a code lint for example will be completely different from a message lint.

Rename lint-rule to message-lint-rule and avoid complicated future proof logic

[samuelstroschein]

Marketplace manifest should be outside of runtime

Context

marketplace information is retrieved via plugin.meta.marketplace which convolutes necessary runtime information like meta.id with additional marketplace information.

Cons

• we need to change this anyways to non code/runtime logic as @felixhaeberle remarked
• because its contained in runtime we require build steps and import logic
• only works for plugins and lint rules which leads to apps, libraries being hardcoded in marketplace

Proposal

man, let's just introduce a marketplace-manifest.json file which the registry fetches. removing packages as a concept enables this.

{
  type: "App" | "Plugin" | "MessageLintRule" | "Library" 
  // different schema based on type
  }

[samuelstroschein]

All observations have been implemented