Adding file standard validation in repository#2849
Adding file standard validation in repository#2849sokra merged 3 commits intowebpack:masterfrom willmendesneto:add-editorconfig-validation
Conversation
Current coverage is 91.06% (diff: 100%)@@ master #2849 diff @@
==========================================
Files 236 236
Lines 9644 9644
Methods 1780 1780
Messages 0 0
Branches 1936 1936
==========================================
- Hits 8783 8782 -1
- Misses 861 862 +1
Partials 0 0
|
|
@sokra @TheLarkInn Could you take a look and see what's going on with the coveralls, please? I think that is some unstable behaviour, because the first time was ok and right now the value was decreased, but nothing was changed in the tests. |
|
@willmendesneto I will take a look at this locally. I don't have access to rerun the coverage reporters but I can atleast make sure everything is passing locally. |
|
@TheLarkInn exactly. Looks weird because nothing was changed. By the way, thanks for feedback. |
|
No prob. And just a heads up Tobias is out for the next couple of weeks so I don't want you to feel we are ignoring PR's I'm simply more comfortable with him merging core changes even if they are pretty harmless like this one. |
| trim_trailing_whitespace=true No newline at end of file | ||
| [*] | ||
| indent_style = tab | ||
| indent_size = 2 |
There was a problem hiding this comment.
Currently, we have indent_size with 2 in the repository. Are we thinking in change this? Because this change has a big impact o a lot of other files.
There was a problem hiding this comment.
We should have tabs everywhere, so this is just a visual change. Can we omit it and let the user use his own default?
There was a problem hiding this comment.
Sorry @sokra, but it's not clear to me. Can you elaborate your question, please?
This configuration is only for this repository, so the user that is consuming/using the package can use other configuration.
There was a problem hiding this comment.
My question was: What is the effect of indent_size when using indent_style = tab? Afaik it's only effect is how width the editor displays tabs. So it's only a visual effect. If this is true the next question is: Can we omit indent_size in .editorconfig so the editor (default) setting comes into effect? Why: Because every collaborator then sees his own default settings.
There was a problem hiding this comment.
Oh, now I got it. No, it's not visual only.
What happens is that when we are using indent_style = tab with indent_size = 2 we are configuring our tab to use 2 spaces by default. So, in this case, every tab will be based in 2 spaces.
We idea is define the configuration in the repository and every collaborator should follow this configuration to avoid files with different styles/code standards. If someone tries to unfollow this default configuration, the build will breaks.
|
@sokra I sent the changes and the build is broken, but I didn't change any related file. Can you check that, please? |
| "travis": "npm run cover -- --report lcovonly", | ||
| "appveyor": "mocha --harmony --full-trace", | ||
| "lint": "eslint lib bin hot", | ||
| "lint-files": "npm run lint && npm run beautify-lint", |
|
I realised that this PR is broken, but there's nothing related to these changes, because I found the same unstable behaviour in other PR's that were merged into master branch, such as: I tried to find the broken code and seems that the Travis-CI starts to break in this build. @sokra @TheLarkInn Can you please check the master build? |
|
Fixed. @sokra @TheLarkInn Could you take a look again, please? |
|
@sokra @TheLarkInn Any updates in this PR? Is able to merge? |
|
@sokra @TheLarkInn how I didn't receive any feedback I'm closing this one. |
|
Sorry about this @willmendesneto we've been pretty swamped with loader API changes. We are still willing to get to this, it is just a matter of it moving kind of slow. If you are willing to reopen we will get to it |
Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
What is the current behavior? (You can also link to an open issue here)
Currently someone can add files that are not respecting the
.editorconfigconfigurations.What is the new behavior?
The goal in this PR is add standard validation in files, based in
.editorconfigdefault configurations. So the build should failure if someone change/add files without respect the current configuration.Does this PR introduce a breaking change?
If this PR contains a breaking change, please describe the following...
This PR doesn't have breaking changes.
Other information: