Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recognize .hocon files by default #24

Open
farquet opened this issue Dec 3, 2019 · 5 comments
Open

Recognize .hocon files by default #24

farquet opened this issue Dec 3, 2019 · 5 comments

Comments

@farquet
Copy link

farquet commented Dec 3, 2019

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 ?

@ghik
Copy link
Collaborator

ghik commented Dec 3, 2019

Yes, it makes sense, but it will also require changing semantics of includes 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.

@farquet
Copy link
Author

farquet commented Dec 3, 2019

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 ?

@ghik
Copy link
Collaborator

ghik commented Dec 4, 2019

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

@farquet
Copy link
Author

farquet commented Dec 4, 2019

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.

@ghik
Copy link
Collaborator

ghik commented Dec 5, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants