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

decorators-style conflicts with Prettier #27

Open
EvgenyOrekhov opened this issue Apr 30, 2021 · 5 comments
Open

decorators-style conflicts with Prettier #27

EvgenyOrekhov opened this issue Apr 30, 2021 · 5 comments
Labels

Comments

@EvgenyOrekhov
Copy link

We're using default Prettier options and default @stencil/decorators-style options.

Prettier formats code like this:

class AxsTreeViewItem {
  @Event({ bubbles: true, composed: true })
  axsTreeItemSelected: EventEmitter<any>;
}

but @stencil/decorators-style says The @Event decorator can only be applied as inline.

I expect @stencil/decorators-style to work with Prettier and to not cause warnings.

@EvgenyOrekhov
Copy link
Author

eslint-plugin-decorator-position had the same bug: NullVoxPopuli/eslint-plugin-decorator-position#289. They fixed it in NullVoxPopuli/eslint-plugin-decorator-position@b86643a. I hope that can be of some help.

@joshmiller83
Copy link

joshmiller83 commented Mar 22, 2022

Chiming in that my CI is now broken because of this incompatibility between stencil.js and prettier. After reading the above, I've become frustrated because I have no idea how to make my CI tools get along with each other.

Edit: I had to add this line to.prettierignore to get the CI to pass, and I found a developer from about a year ago had to do the same thing for the same reason 🤦:

# Stencil files with @Event
src/components/generic-tab/xxx-tab.tsx
src/components/generic-tab-panel/generic-tab-panel.tsx

I also had to add this to .eslintignore. I don't know why my tab-panel event required hiding this from both systems.

# Stencil files with @Event
src/components/generic-tab-panel/generic-tab-panel.tsx

@nioe
Copy link

nioe commented May 4, 2022

I guess this issue can be closed, since Prettier does not change decorators anymore (see here).

Furthermore, you're still able to configure Stencil's ESlint plugin according to your needs, i.e. set all Decorator-Styles to multiline:

{
  "parserOptions": {
    "project": "./tsconfig.json"
  },
  "extends": ["plugin:@stencil/recommended"],
  "rules": {
    "@stencil/decorators-style": [
      "error",
      {
        "prop": "multiline",
        "state": "multiline",
        "element": "multiline",
        "event": "multiline",
        "method": "multiline",
        "watch": "multiline",
        "listen": "multiline"
      }
    ]
  }
}

@EvgenyOrekhov
Copy link
Author

@nioe Prettier behavior is still the same. And I expect default decorators-style options to be compatible with Prettier. So keeping the issue open.

@nioe
Copy link

nioe commented May 4, 2022

@EvgenyOrekhov Your example is a bit missleading since Prettier doesn't reformat the line based on the set decorator, but because the printWidth, which is set to 80 by default, is exceeded. This behavior is described as well in the link I posted above:

We haven’t been able to find a good rule for this, so Prettier keeps your decorator positioned like you wrote them (if they fit on the line). This isn’t ideal, but a pragmatic solution to a difficult problem.

If you set the printWidth to 85 your example does not change the decorator anymore. See here.

I can understand your proposal, but since you can configure it to your needs if you use Stencil's ESlint Plugin and Prettier at the same time, I do not see a reason why the opinionated default of Stencil should be changed...

In the end of the day, this is of course the decision of the maintainers. I just wanted to show the possibility based on already implemented features, how to get it up and running in case somebody stumbles upon this issue...

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

No branches or pull requests

4 participants