Open farquet opened 4 years ago
Yes, it makes sense, but it will also require changing semantics of include
s so that include "foo"
could be interpreted as include "foo.hocon"
(and that include "foo.hocon"
is not interpreted as include "foo.hocon.conf"
). I'm not yet 100% sure if this is fine with respect to HOCON spec.
Good point. According to the specification :
Implementations may support including files in other formats.
[...]
If a filename has no extension, the implementation should treat it as a basename and try loading the file with all known extensions.
If the file exists with multiple extensions, they should all be loaded and merged together.
Files in HOCON format should be parsed last. Files in JSON format should be parsed next-to-last.
So, it basically says that it is up to the implementer to decide, which is not so cool...
On one hand we can argue that if one uses non-official extensions, it's that person's responsability to be explicit in the include statements.
On the other hand, .hocon
seems again so unambiguous that I don't see any danger in considering it a first class citizen.
I don't have any strong opinion on this, maybe the best would be to mimic the behavior of the most popular hocon implementation ?
I don't have any strong opinion on this, maybe the best would be to mimic the behavior of the most popular hocon implementation ?
Well, that would be not recognizing the .hocon
extension. Lightbend Config treats foo.hocon
as filename with no extension and tries to interpret it as .conf
or .json
or .properties
. This is not a hard limitation in practice because Lightbend Config lets you implement your own ConfigIncluder
which can override this behaviour.
However, it ultimately looks like recognizing .hocon
files by default would be against the default behaviour of the most popular HOCON implementation...
However, it ultimately looks like recognizing .hocon files by default would be against the default behaviour of the most popular HOCON implementation...
My point is that it is very likely that a user would like his/her .hocon
files to be automatically detected by the plugin and formatted nicely.
But this is independent from the final choice about includes. One could decide to recognize those files in the IDE, but force the user to be explicit in code while treating .hocon
files.
I understand the motivation, but as for me this is a perfect example of something that the user should configure manually. Automatically having .hocon
files recognized as HOCON and not recognizing them in includes seems ugly inconsistent to me. But I'll have to sleep over this.
Even though most of HOCON files are
.conf
files, it is also common to come across projects using the.hocon
extension.Since it's unambiguous and already used by big projects like GraalVM as one can see here, would it be possible to also recognize those by default such that users don't need to manually add it ?