prettier / prettier-vscode

Visual Studio Code extension for Prettier
https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode
MIT License
5.04k stars 446 forks source link

Create option to ignore files (like webpack.config.js) #57

Closed raphi011 closed 6 years ago

raphi011 commented 7 years ago

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

esbenp commented 7 years ago

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

raphi011 commented 7 years ago

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

CiGit commented 7 years ago

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.

raphi011 commented 7 years ago

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!

CiGit commented 7 years ago

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 :-)

kengoldfarb commented 6 years ago

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

CiGit commented 6 years ago

What's your use case ?

kengoldfarb commented 6 years ago

@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.

CiGit commented 6 years ago

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

kengoldfarb commented 6 years ago

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.

mgutz commented 6 years ago

@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.

CiGit commented 6 years ago

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

tereshhhchenko commented 6 years ago

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?

tereshhhchenko commented 6 years ago

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.

ButuzGOL commented 6 years ago

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

CiGit commented 6 years ago

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

ButuzGOL commented 6 years ago

yes but as understand this feature is not released yet

CiGit commented 6 years ago

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

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)

azz commented 6 years ago

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.

CiGit commented 6 years ago

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

joaovieira commented 6 years ago

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

CiGit commented 6 years ago

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

jantimon commented 6 years ago

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

CiGit commented 6 years ago

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

jackson-sandland commented 6 years ago

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

github-actions[bot] commented 4 years ago

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.