Prettier-vscode: Create option to ignore files (like webpack.config.js)

Created on 30 Mar 2017  路  26Comments  路  Source: prettier/prettier-vscode

Hi! I'd love to have an option to include / exclude paths or files so that my webpack.config.js doesn't get ruined everytime I save the file

enhancement locked

Most helpful comment

I was mentioning //prettier-ignore which is not for an entire file and thus doesn't let us pass it to the next formatter (I think).

And I've seen a use case: not all files are processed the same way, build files vs babel files.
For that case I think the right solution would be to provide different options (trailing-comma I can think of) but that's an other issue :-)

All 26 comments

Seems like a good idea to me. Would you dare to take a crack at a PR?

yea sure, i'll try to get to it this week :)

If you find your webpack config getting ugly maybe the best thing to do would be to open an issue on prettier.
I'm not against that option even if I personally see no use case currently. You can still put a // prettier-ignore on a block you don't want prettier to modify.

If this is tackled, I think it shouldn't break EVERY formatter, this way you can still format your ignored files with the default formatter (or any other formatter) to have it indented correctly.

I went to the prettier issues and someone asked a similiar question here.

They said we should create an option for the extensions which use prettier, not for prettier itself.

I agree with not breaking other formatters!

I was mentioning //prettier-ignore which is not for an entire file and thus doesn't let us pass it to the next formatter (I think).

And I've seen a use case: not all files are processed the same way, build files vs babel files.
For that case I think the right solution would be to provide different options (trailing-comma I can think of) but that's an other issue :-)

Any movement on this issue lately? It'd be a really helpful feature to have.

What's your use case ?

  • Ignore files completely
  • Having different config per language
  • Having different config per files (same language)
  • Other?

@CiGit ignoring files completely. Specifically, I'm seeing prettier destroy my flow-type module definitions. Temporarily turning off format on save or putting in a bunch of // prettier-ignore comments is a workaround but not ideal.

Would prettier/prettier#2195 fit your needs? I won't duplicate a feature which may be in prettier ;-)

Yes, if they actually implement it. However, https://github.com/prettier/prettier/issues/1428 and https://github.com/prettier/prettier/issues/787 makes it look like it hasn't been a priority.

@CiGit Prettier raises an error when saving vscode's settings.json. See Microsoft/vscode#29701. Obviously it's not valid JSON since it has comments but it's how the configuration is. Would be nice to be able to ignore that file.

Hum ... right...
As a current work around:

  • Disable formatOnSave
  • set prettier.jsonEnable:[] (ie disable 'json' formatting)
  • Remove // Place your settings in this file to overwrite the default settings and any other comment. But it may still fail with a trailing comment.
    Edit: Choose one of those.

I have the same issue with webpack.config.js - I don't want to run prettier for this file.
I tried to add webpack.config.js in .eslitignore and in eslintIgnore in package.json.
No luck.

It would be nice if Prettier could take .eslitignore into account.

I also tried to use overrides

{
"overrides": [{
    "files": ["webpack.config.js"],
    "rules": {
      "comma-dangle": ["error", "never"]
    }
  }]
}

But it didn't work for me: both prettier and eslint plugin for vscode ignore that.

Am I doing smth wrong?

My project's simplified structure:

[dev]
[test]
webpack.config.js
.eslintrc

What I ended up is to move my eslint config into a folder and create multiple .eslintrc files that extend from base config.

[eslint-config]
    .eslintrc  // Actual configuration
[dev]
    .eslintrc 
        { "extends": "../eslint-config/.eslintrc" }
[test]
    .eslintrc 
        { "extends": "../eslint-config/.eslintrc" }
webpack.config.js
.eslintrc
     { "extends": "./eslint-config/.eslintrc",  "rules": {  "comma-dangle": ["error", "never"] } }

Not clean enough, but at least works.

vote for this feature because i have three projects in one env and only one is using Prettier and it makes big pain to enable/disable formatOnSave

Will a .prettierignore fit your needs?
https://github.com/prettier/prettier/pull/2412

yes but as understand this feature is not released yet

Not yet, maybe in next prettier release (it has been merged) :-)
While we are at it:

  • Prevent formatting only on formatOnSave
  • Prevent formatting always (formatOnSave, User wants to format)

Arguments so far:

Prevent on save

@azz

Its bad UX to format something on save that should be formatted. When it is an explicit action (like alt-shift-f) the UX is ok.

Certainly was should NOT be formatted

Prevent always

@cigit

If you ignore it, means you don't want it to be formatted, ever. We will prevent a mistake.

Side note

This is not an argument but we can't implement to prevent only on save without changing the complete architecture. VSCode's API doesn't give us any reason on why format was called (maybe I've not found)

To be clear, I wasn't arguing _for_ prevent only on save, I was explaining why it is something people will tend to expect from the extension.

@azz Got it :-) and you are right.
In the end it will still do something: Log a message (in any case).

Can't wait for this. Tired of unnecessary git diffs in package.json as npm also formats it on each install.

We still have to do it. @joaovieira volunteer ? :smiley: #198

Could we just ignore all files from .gitignore? (might be a setting)

It should once implemented. I see a new settings called ignorePath which defaults to _.prettierignore_ syntaxe is the same as a the one used in _gitignore_

This would be a great feature. Why would we want to prettify anything in .gitignore - especially node_modules?

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings