unic
Include .idea configuration files for Webstorm
IDE configuration files should not be checked into projects, but rather get generated on client-side. I would strongly advice against this change.
If there is something which needs to be configured in Webstorm manually after checkout, chances are that there is a gulp way of providing this configuration, which then would be IDE agnostic.
This comes from #28, since then I have too many files around annoying. If there's a better solution (considering what is documented in #28) I'm open to suggestions, of course ;) Maybe you @DaniRey or @swey have a better hint?
Learned something thanks to #28 . But I remain critical.
I think projects should not contain configuration for specific IDEs. In my opinion:
- Code inspection should be part of the linting process.
- Encoding should be UTF-8
- git submodule is handled in git (what do we have to configure in the IDE for this?)
- doesn't Webstorm recognize the usage of ES6 automatically?
At least for backend projects I never have to configure anything in Intellij. Everything is derived from Maven, SBT or Gradle.
IDE configuration files should not be checked into projects,
While I think they should not be included in this estatico repository, It's useful and not uncommon to have them in the projects.
Everything is derived from Maven, SBT or Gradle.
Yes, but for example Maven has settings for modules and so on. We don't have a possibility to define a project structure across different IDEs - there is no standard yet (.editorconfig only has a few config options). If you want new team members to checkout a project without giving them your settings and project structure manually, you need to include those IDE-related config files. (But as said before: I would not recommend to included in this specific case.)
While I think they should not be included in this estatico repository, It's useful and not uncommon to have them in the projects.
I could agree on the idea of having the project clean of IDE specific files. How do you then handle those files? We removed them from .gitignore, so they are now annoying all the time in git status. Any suggestion on how to handle them?
@orioltf, as a rather ugly workaround you could add another .gitignore to the parent directory...
@orioltf, should we add them back to the .gitignore and leave it to the projects whether to customize their .gitignore to possibly r"e-allow" them?