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 max_line_length=off when parsing .editorconfig? #14514

Closed
josephfrazier opened this issue Mar 15, 2023 · 9 comments · Fixed by #14516
Closed

Support max_line_length=off when parsing .editorconfig? #14514

josephfrazier opened this issue Mar 15, 2023 · 9 comments · Fixed by #14516
Labels
locked-due-to-inactivity Please open a new issue and fill out the template instead of commenting.

Comments

@josephfrazier
Copy link
Collaborator

josephfrazier commented Mar 15, 2023

TL;DR: Should max_line_length=off in .editorconfig get interpreted as printWidth: Number.MAX_SAFE_INTEGER, or should we continue ignoring it, or something else?

Hey everyone, I'm the maintainer of editorconfig-to-prettier, which Prettier uses to convert EditorConfig configuration to Prettier configuration.

Over 5 years ago, bug #3410 was reported regarding the handling of max_line_length=off, and resulted in @duailibe fixing editorconfig-to-prettier to ignore max_line_length=off in .editorconfig files (the corresponding dependency version bump can be found here).

However, there's been some renewed interest from @celluj34 in having Prettier interpret max_line_length=off to mean e.g. printWidth: A_REALLY_BIG_NUMBER like Number.MAX_SAFE_INTEGER.

My question is, would this cause unintended consequences? For example, would Prettier attempt to generate very long lines for files where max_line_length=off? I see that https://prettier.io/docs/en/options.html#print-width says:

In other words, don’t try to use printWidth as if it was ESLint’s max-len – they’re not the same. max-len just says what the maximum allowed line length is, but not what the generally preferred length is – which is what printWidth specifies.

but I wonder if it would be ok in practice. I took a quick look at the playground with --print-width set to 9999, and the output seems reasonable-ish:

function HelloWorld({ greeting = "hello", greeted = '"World"', silent = false, onMouseOver }) {
  if (!greeting) {
    return null;
  }

  // TODO: Don't use random in render
  let num = Math.floor(Math.random() * 1e7)
    .toString()
    .replace(/\.\d+/gi, "");

  return (
    <div className="HelloWorld" title={`You are visitor number ${num}`} onMouseOver={onMouseOver}>
      <strong>{greeting.slice(0, 1).toUpperCase() + greeting.slice(1).toLowerCase()}</strong>
      {greeting.endsWith(",") ? " " : <span style={{ color: "grey" }}>", "</span>}
      <em>{greeted}</em>
      {silent ? "." : "!"}
    </div>
  );
}

Part of me thinks that if someone is explicitly putting max_line_length=off in their .editorconfig, then they should be ok with this formatting. On the other hand, I haven't really used Prettier for a while now, and I'm not very familiar with the variety of use cases people have for it, so I thought I'd ask here.

What do you think? Should max_line_length=off in .editorconfig get interpreted as printWidth: Number.MAX_SAFE_INTEGER, or should we continue ignoring it, or something else?

Thanks!

@fisker
Copy link
Sponsor Member

fisker commented Mar 15, 2023

It make sense to support it.
Let's parse it as Infinity.

printWidth: Number.POSITIVE_INFINITY,

@josephfrazier
Copy link
Collaborator Author

josephfrazier commented Mar 15, 2023

Oh, thanks for pointing that out, we're already using a "really big number" in a handful of places.

I'll probably wait on some other maintainers to chime in before making any changes in my package, but I appreciate the feedback 👍🏻

@fisker
Copy link
Sponsor Member

fisker commented Mar 15, 2023

I think we can also improve the doc printer by skipping this check if printWidth is Infinity.

function fits(next, restCommands, width, hasLineSuffix, mustBeFlat) {

@josephfrazier
Copy link
Collaborator Author

josephfrazier commented Mar 16, 2023

I'll probably wait on some other maintainers to chime in before making any changes in my package, but I appreciate the feedback 👍🏻

Oh lol, I see now that you're the primary contributor nowadays (this year so far)

image

I'd be happy to publish a new version of editorconfig-to-prettier that converts max_line_length=off to printWidth: Number.POSITIVE_INFINITY, but I'm not sure if I can help out with the adding tests/optimizations here in the Prettier repo (but I might try!). How does that sound?

@fisker
Copy link
Sponsor Member

fisker commented Mar 16, 2023

How does that sound?

I think it's the right thing to do from perspective of editorconfig-to-prettier. We can decide accept it or not when upgrading it. We can choose to ignore after all https://github.com/prettier/prettier/blob/d797f0cff203e4894295e9a021e55f8feefc89ab/src/config/resolve-editorconfig.js#L14-L15😄

@celluj34
Copy link

delete config.insertFinalNewline;

😭😭😭

@fisker
Copy link
Sponsor Member

fisker commented Mar 16, 2023

delete config.insertFinalNewline;

😭😭😭

#10759 (comment)

@celluj34
Copy link

#10759 (comment)

I know; but I am on the "would like to have the option for trailing newlines" camp.

josephfrazier added a commit to josephfrazier/editorconfig-to-prettier that referenced this issue Mar 16, 2023
…ITY` (#10)

This fixes #7, see prettier/prettier#14514 for more context:

> **TL;DR: Should `max_line_length=off` in `.editorconfig` get interpreted as `printWidth: Number.MAX_SAFE_INTEGER`, or should we continue ignoring it, or something else?**
>
> Hey everyone, I'm the maintainer of [editorconfig-to-prettier](https://www.npmjs.com/package/editorconfig-to-prettier), which [Prettier uses](https://github.com/prettier/prettier/blob/5446a8f32a2717762c4d7a1bd5fe2615d76ebec7/src/config/resolve-config-editorconfig.js#L6) to convert [EditorConfig](https://editorconfig.org/) configuration to Prettier configuration.
>
> Over 5 years ago, bug #3410 was reported regarding the handling of `max_line_length=off`, and resulted in @duailibe [fixing `editorconfig-to-prettier` to ignore `max_line_length=off` in `.editorconfig` files](#3) (the corresponding dependency version bump can be found [here](prettier/prettier#3412)).
>
> However, there's been some [renewed interest](#7 (comment)) from @celluj34 in having Prettier interpret `max_line_length=off` to mean e.g. `printWidth: A_REALLY_BIG_NUMBER` like [Number.MAX_SAFE_INTEGER](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER).
>
> My question is, would this cause unintended consequences? For example, would Prettier attempt to generate very long lines for files where `max_line_length=off`? I see that https://prettier.io/docs/en/options.html#print-width says:
>
> > In other words, don’t try to use printWidth as if it was ESLint’s [max-len](https://eslint.org/docs/rules/max-len) – they’re not the same. max-len just says what the maximum allowed line length is, but not what the generally preferred length is – which is what printWidth specifies.
>
> but I wonder if it would be ok in practice. I took a quick look at [the playground with `--print-width` set to 9999](https://prettier.io/playground/#N4Igxg9gdgLgprEAuEAzArlMMCW0AEAEnADYkQDqEATiQCYAUwA5tXHLlM-gLz4A6IABalyggDT5W7eHV74A5IKq06ghZIDOOEghjzUAQxKa4k6AFkI6UwHkAbnGriAvgEp8wflG-58OVAYAQmkOHC43YDYYdGoofCh0MhcAbm9fPz8Aeiz8ABVbABFbJHxC6AV9Gzh8akMoOggAW394tganDN19RJa+C0MYIQA6VHIafAYBoeG6huaGDwAqfABGAFEAagB2N2GYCABlGGpw5kXZuAAHEkMwOAYs-n5h57pNrJxmSUFBN3T4rUOLF4gAeOg4ez4MC3TSaAByhiacB4CmIZEoNHoCnwuBguh4wAABgBNaz4QxsfD2HDaA7UBLoJoAIyc+AAJMBGS0XESXPhLNY7I5qITBdUHE4XAA+AGZfCgzQnaDMaVc0KcZjDTQkHD3Bj4AAMklW+D2BwAqlcrk4AMKGUyLfCbKRsMJcbW6-Wrc0QAAyEAA7naHQ8PC5QVkldQVbLAX4WG7NcMEHRNBQcEMGBI-vgAPwCECF-ClRVXer4JUATwJwGAkHI1FKSn40irChcMokhcjmnLUGl+BcGT8oLgTTj-Bg6qTcDkw58MEj47j8q5DG0ulg-3jmQLgleIBHmVKgiCggXx8jEPs0rSPigLhA4hAECuuGgmmQoEpMcDAAVKQQL8UGMQNDCrL8X2ZOowAAaw4Q4kTgP1wjgZAjBMMwQBgu4EJgQ5yzAM5kBOdBsPHVk6DoOc-XqZh0EMZg4AAMRoJpBk1ZAQEMdADmfYQYCaEgKCETM4D7O44EOYDM0hTMq24sA4QE8JTGoGB-zqZgOIw4xTBfAArTQAA9DjOXQAEV0AgeA9Kwl9y2odTuOZQxWRIASrhjUwKDqK5uO8iSnEcASAEcbPgLS3xAnjNAAWigdgaLoAS2AinA2C0pjdKQTCDJAUwmhwUjqHIl9tC4XQAEEYBOHBmT4uB-ycVCkvsgrKuYKzIvQvL9OwmB3IzOghmQAAmF8TkMHQzltZpcpACSAFYBOqPJ3JA-LsPsciAEkOlgQ4wFOd9qoaY4az67bHNOWARrGpAAE4XqezsgA), and the output seems reasonable-ish:
>
> ```js
> function HelloWorld({ greeting = "hello", greeted = '"World"', silent = false, onMouseOver }) {
>   if (!greeting) {
>     return null;
>   }
>
>   // TODO: Don't use random in render
>   let num = Math.floor(Math.random() * 1e7)
>     .toString()
>     .replace(/\.\d+/gi, "");
>
>   return (
>     <div className="HelloWorld" title={`You are visitor number ${num}`} onMouseOver={onMouseOver}>
>       <strong>{greeting.slice(0, 1).toUpperCase() + greeting.slice(1).toLowerCase()}</strong>
>       {greeting.endsWith(",") ? " " : <span style={{ color: "grey" }}>", "</span>}
>       <em>{greeted}</em>
>       {silent ? "." : "!"}
>     </div>
>   );
> }
> ```
>
> Part of me thinks that if someone is explicitly putting `max_line_length=off` in their `.editorconfig`, then they should be ok with this formatting. On the other hand, I haven't really used Prettier for a while now, and I'm not very familiar with the variety of use cases people have for it, so I thought I'd ask here.
>
> What do you think? Should `max_line_length=off` in `.editorconfig` get interpreted as `printWidth: Number.MAX_SAFE_INTEGER`, or should we continue ignoring it, or something else?
>
> Thanks!

> It make sense to support it. Let's parse it as `Infinity`.
>
> https://github.com/prettier/prettier/blob/5446a8f32a2717762c4d7a1bd5fe2615d76ebec7/src/language-js/print/template-literal.js#L55

> Oh, thanks for pointing that out, [we're already using a "really big number" in a handful of places](https://github.com/search?q=repo%3Aprettier%2Fprettier+%22printwidth%3A+number%22&type=code).
> 
> I'll probably wait on some other maintainers to chime in before making any changes in my package, but I appreciate the feedback 👍🏻

> I think we can also improve the doc printer by skipping this check if `printWidth` is `Infinity`.
> 
> https://github.com/prettier/prettier/blob/5446a8f32a2717762c4d7a1bd5fe2615d76ebec7/src/document/doc-printer.js#L162

> > I'll probably wait on some other maintainers to chime in before making any changes in my package, but I appreciate the feedback 👍🏻
> 
> Oh lol, I see now that you're the primary contributor nowadays ([this year so far](https://github.com/prettier/prettier/graphs/contributors?from=2023-01-01&to=2023-03-15&type=c))
> 
> I'd be happy to publish a new version of `editorconfig-to-prettier` that converts `max_line_length=off` to `printWidth: Number.POSITIVE_INFINITY`, but I'm not sure if I can help out with the adding tests/optimizations here in the Prettier repo (but I might try!). How does that sound?
@josephfrazier
Copy link
Collaborator Author

I think it's the right thing to do from perspective of editorconfig-to-prettier. We can decide accept it or not when upgrading it. We can choose to ignore after all https://github.com/prettier/prettier/blob/d797f0cff203e4894295e9a021e55f8feefc89ab/src/config/resolve-editorconfig.js#L14-L15😄

Perfect, I've published v1.0.0 with the change that converts max_line_length=off to printWidth: Number.POSITIVE_INFINITY, and started on a PR to upgrade Prettier to that version: #14516

josephfrazier added a commit that referenced this issue Mar 18, 2023
This fixes #14514 by
upgrading `editorconfig-to-prettier` with the fix from josephfrazier/editorconfig-to-prettier#10
josephfrazier added a commit that referenced this issue Sep 14, 2023
I'd like to vendor/upstream this code because it's been the topic of a handful of issues in its repo over the years, including josephfrazier/editorconfig-to-prettier#9, josephfrazier/editorconfig-to-prettier#21, and most recently josephfrazier/editorconfig-to-prettier#24, and I feel that having it in-repo would be more appropriate (not to mention [the issues in _this_ repo that pertain to editorconfig parsing](https://github.com/search?q=repo%3Aprettier%2Fprettier+editorconfig++&type=issues&state=open)). I've elaborated on my thoughts in josephfrazier/editorconfig-to-prettier#24 (comment), which I'll quote below:

> hey @Drakmyth, thanks for continuing this conversation! I appreciate all the links you've provided that indicate existing intention and implementations of parsing non-standard/custom properties. It seems like this question might not be as simple as I thought it was previously.
> 
> @fisker, thanks for chiming in as well!
> 
> As you (@fisker) mentioned in [#16 (comment)](josephfrazier/editorconfig-to-prettier#16 (comment)), this package was originally intended for use by Prettier, and while there are some other dependents (according to [github](https://github.com/josephfrazier/editorconfig-to-prettier/network/dependents?dependent_type=PACKAGE) and [npm](https://www.npmjs.com/package/editorconfig-to-prettier?activeTab=dependents)), Prettier is still the vast majority of the usage this package sees.
> 
> Given that, I think it might make sense for this package's code/functionality to move into the Prettier repository, so that any issues relating to it can be discussed where it's used. Personally, I don't use `.editorconfig` with Prettier, so I don't feel especially well-positioned to make decisions on how things should work, especially when [the output of this package is subsequently modified by Prettier](https://github.com/prettier/prettier/blob/7c512651f8814924a042034ff821190c68ef409d/src/config/resolve-editorconfig.js#L13-L16) (I think you had also [mentioned](#14514 (comment)) this previously, @fisker), indicating that its behavior is already divergent from the intended use case.
> 
> What do y'all think of that proposal? If we have https://github.com/prettier/prettier/ vendor this repository's code, then I can archive this repo and direct people to discuss functionality in the Prettier issues.

This also implements @fisker's suggested change to ES module syntax from josephfrazier/editorconfig-to-prettier#16, as it's required for lint/test etc to pass.

Once this is merged, I'll likely archive the https://github.com/josephfrazier/editorconfig-to-prettier/ repo after adding a note directing any visitors here instead.

---

* Vendor editorconfig-to-prettier.js from https://github.com/josephfrazier/editorconfig-to-prettier/blob/8bb8226c40d7f2c8cf629301576850876c8617d4/index.js

* WIP Use `require` instead of `import`

* Revert "WIP Use `require` instead of `import`"

This reverts commit 4656b72.

* Use `export` in editorconfig-to-prettier.js instead of `module.exports`, see josephfrazier/editorconfig-to-prettier#16

Copied from https://raw.githubusercontent.com/josephfrazier/editorconfig-to-prettier/e245d7051f3e2a1153b82362ed241f3f7482ab18/index.js

* `yarn fix`

* Add tests/unit/editorconfig-to-prettier.js from josephfrazier/editorconfig-to-prettier#16

Copied from https://raw.githubusercontent.com/josephfrazier/editorconfig-to-prettier/9effd580e7b6722007e1ace9913512e450cda46f/test.js

* tests/unit/editorconfig-to-prettier.js: Fix path to implementation

* WIP Naively convert assert.deepEqual to expect/toStrictEqual, see #15394 (comment)

* Wrap `test()` around `expect` calls

* XXX Force a middle test to fail to ensure the syntax works

* Revert "XXX Force a middle test to fail to ensure the syntax works"

This reverts commit 947eb34.

* `yarn fix`
josephfrazier added a commit to josephfrazier/prettier that referenced this issue Sep 14, 2023
…ne` to `insertFinalNewline`

Now that prettier#15394 has been
merged, this addresses prettier#14514 (comment)
josephfrazier added a commit that referenced this issue Sep 14, 2023
…ert_final_newline` to `insertFinalNewline` (#15398)

EditorConfig handling: Remove parsing/ignoring of `insert_final_newline` to `insertFinalNewline`

Now that #15394 has been
merged, this addresses #14514 (comment)
@github-actions github-actions bot added the locked-due-to-inactivity Please open a new issue and fill out the template instead of commenting. label Nov 26, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 26, 2023
medikoo pushed a commit to medikoo/prettier-elastic that referenced this issue Jan 4, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked-due-to-inactivity Please open a new issue and fill out the template instead of commenting.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants