Plugins and dependency injection

[bd82]

Hello.

I am trying to give a boost to the prettier-java plugin which was moved to the Jhipster
organization.

• https://github.com/jhipster/prettier-java
  I am new to prettier internals so please bear with me 😄

I am trying to understand the relationship between a plugin and prettier itself.
I see that most of the plugins listed in: https://github.com/prettier/prettier/blob/master/docs/plugins.md
specify a direct dependency to prettier in their package.json.

I also see that the plugin development guide:

• https://github.com/prettier/prettier/blob/master/docs/plugins.md#printers
  Provides a code snippet that creates a direct dependency:

const { concat, join, line, ifBreak, group } = require("prettier").doc.builders;

Does it make sense that a plugin depends on the core platform directly?
Won't that cause multiple versions of prettier to exist at the same time?
Should not the core platform load the plugin and provide the APIs in some kind of DI injection style?
e.g:

// This function get invoked by prettier when it loads the discovered plugins
function initBuilders(prettier_core_builders) {
   const { concat, join, line, ifBreak, group } = prettier_core_builders;
}

module.exports = { initBuilders };

Thanks.
Shahar.

[j-f1]

As long as you use ^-style ranges, you shouldn’t have issues with duplicated Prettier versions.

[ikatyang]

Yeah, I thought about it before (recursive dependency). But since nobody raised this kind of issues, I didn't investigate it further. We should change it to not directly depend on prettier, though it'll make the development inconvenient (we cannot do top-level require to get doc-related method, we need to pass it to every function that needs this functionality).

[j-f1]

How about creating a @prettier/doc-builders package that both core and plugins depend on?

[bd82]

As long as you use ^-style ranges, you shouldn’t have issues with duplicated Prettier versions.

That would be much better and I will apply it, but it only solves the problem for minor versions not major versions.

How about creating a @prettier/doc-builders package that both core and plugins depend on?

This seems like a better way, but if the internal structure of the Doc changes it would be a breaking change. For example: if pluginX uses doc-builders@1.2.0 and prettier uses doc-builders@2.1.0 and those two versions produce a different Doc object than we will have a problem.

On the other hand if the interface for building a Doc object:

• Is Well defined.
• Won't change in prettier major version changes.
• will be Injected to plugins.

It would mean that plugins could even be re-used across major versions of prettier.
So if/when prettier 2.0 is released due to some breaking change in the consumer API (unrelated to plugins). It would not require all plugins to release new versions too.