Reload Ktlint's caches when .editorconfig changes
#265
Conversation
|
Any progress on this? @jeremymailen @mateuszkwiecinski |
Sorry for the delay. I was on vacation and then sick, so side projects haven't gotten much attention lately. |
src/main/kotlin/org/jmailen/gradle/kotlinter/support/EditorConfigUtils.kt
Show resolved
Hide resolved
| return generateSequence(seed = projectEditorConfig) { editorconfig -> | ||
| if (editorconfig.isRootEditorConfig) { | ||
| null | ||
| } else { | ||
| editorconfig.parentFile?.parentFile?.resolve(".editorconfig") | ||
| } | ||
| } |
There was a problem hiding this comment.
This implementation does find .editorconfig files located in the current directory or in any parent. Also it is nice that you stop visiting parent directories when you encounter the "root=true" property.
What I do miss however, but I might be wrong, is checking for .editorconfig files inside the project itself. Don't they need to be detected and listed beforehand?
There was a problem hiding this comment.
What I do miss however, but I might be wrong, is checking for .editorconfig files inside the project itself. Don't they need to be detected and listed beforehand?
I think this is a valid comment 👀 Although I'd avoid blindly traversing through project sources looking for potential editorconfig files. I claim most project use single editorconfig defined at Gradle's rootProject + in advanced use cases users override its settings by setting another editorconfig at Gradle project level (i.e. to have different formatting for generated files committed to the repository).
I'll still suggest going with what I proposed here, at least for now, as I believe it addresses most cases plus most likely it'll be fixed when we switch to the new api you'll introduce for pinterest/ktlint#1446
| resetEditorconfigCacheIfNeeded( | ||
| wasEditorConfigChanged = parameters.wasEditorConfigChanged, | ||
| logger = logger, | ||
| ) |
There was a problem hiding this comment.
Instead of resetting the entire cache of KtLint, we can also add a new API to KtLint that just evicts or directly reloads an editorconfig file based on its pathname. That would be an easy change. As API consumer you will be in full control to respond on changes in .editorconfig files that you are aware of. Last but not least, it is not needed to reload the entire cache.
|
I assume we'll update this PR after #275? |
mateuszkwiecinski
force-pushed
the
fix_editorconfig
branch
from
a88d650 to
dcf068b
Compare
mateuszkwiecinski
force-pushed
the
fix_editorconfig
branch
from
dcf068b to
0c897be
Compare
mateuszkwiecinski
changed the title
.editorconfig changes.editorconfig changes
Yes exactly. I waited until |
src/main/kotlin/org/jmailen/gradle/kotlinter/support/EditorConfigUtils.kt
Show resolved
Hide resolved
| return generateSequence(seed = projectEditorConfig) { editorconfig -> | ||
| if (editorconfig.isRootEditorConfig) { | ||
| null | ||
| } else { | ||
| editorconfig.parentFile?.parentFile?.resolve(".editorconfig") | ||
| } | ||
| } |
There was a problem hiding this comment.
What I do miss however, but I might be wrong, is checking for .editorconfig files inside the project itself. Don't they need to be detected and listed beforehand?
I think this is a valid comment 👀 Although I'd avoid blindly traversing through project sources looking for potential editorconfig files. I claim most project use single editorconfig defined at Gradle's rootProject + in advanced use cases users override its settings by setting another editorconfig at Gradle project level (i.e. to have different formatting for generated files committed to the repository).
I'll still suggest going with what I proposed here, at least for now, as I believe it addresses most cases plus most likely it'll be fixed when we switch to the new api you'll introduce for pinterest/ktlint#1446
Fixes #262
It seems like this was the scenario I mentioned in: #246 (comment) 😅
My proposal is to do basically the same thing as ktlint-gradle does 🤷 Maaybe if pinterest/ktlint#1446 gets addressed we'll get appropriate api to know when something changes (or ktlint will be smart enough to track
.editorconfigchanges)