Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Prettier 2? #668

Open
TenPotatoes opened this issue May 8, 2024 · 1 comment
Open

Support Prettier 2? #668

TenPotatoes opened this issue May 8, 2024 · 1 comment

Comments

@TenPotatoes
Copy link

I'm running prettier-java from a separate package, which doesn't work since Prettier 3 seems to require that plugins are in the same package.

I tried Prettier 2 but got this error on prettier-java version 2.6.0 but not 2.0.0

[error] require() of ES Module ..../node_modules/prettier-plugin-java/dist/index.js from ..../node_modules/prettier/index.js not supported.
[error] Instead change the require of ..../node_modules/prettier-plugin-java/dist/index.js in ..../node_modules/prettier/index.js to a dynamic import() which is available in all CommonJS modules.
@jtkiesel
Copy link
Contributor

As I understand it, this would require us to provide a CommonJS module in addition to our current ECMAScript Module. Normally, I think this would be as "simple" as transpiling our ECMAScript Module to CommonJS. I could be wrong, but I don't believe that is possible without downgrading our version of Chevrotain (the parser building toolkit used to build the Java parser leveraged by this plugin), as version 11 dropped support for CommonJS Modules.

If there were a relatively easy fix for this, I would consider it, but I don't know that we'll put much effort into supporting an unmaintained major version of Prettier (Prettier has not released any new 2.x versions since 3.0.0 was released, over a year ago). For now, you'll likely need to stick with prettier-plugin-java 2.5.0, until you can upgrade to Prettier 3.

I'm not sure of your exact use case for needing Prettier and its plugins to be in different packages, but it sounds atypical. I would recommend rethinking that, if possible. If you explain why this is necessary, I may be able to offer better advice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants