Config file should have the extension .json

[kytrinyx]

The file is a .json file, not a .go file.

To fix this we'll need a workaround that moves an .exercism.go file before any command that requires it for the lifetime of the 1.x version of the library.

Originally reported in tandem with another issue in #24

[TrevorBramble]

Started noodling on this last night. Did you have any particular approach you wanted to see?

[kytrinyx]

Nope :) Did you have any specific thoughts about how to approach it?

[TrevorBramble]

I was just going to put a layer of indirection in-between the identification and reading of an existing config file that migrates the file first. After looking through the source though it looked like implementation would be a lot simpler (would require least rework) if it was just a method that was called outside of (ahead of) that workflow that doesn't even care that it's a config file. Just, "if we have this file, move it".

[kytrinyx]

Yeah, that second approach sounds way easier.

[lcowell]

I was thinking about what we need to consider when it comes to renaming the file.

• if the suffix is json, leave the file alone
• if the suffix is go
  • check if a corresponding json file exists
    • if no: rename
    • if yes: panic // or noop ?

I was also thinking about a use supplied configuration file. If the user passes in a file like exercism --config my_other_config.go, should we be renaming that file ? I think as a user that would be surprising to me, so I think we should only rename a file if it's using the default location.

[kytrinyx]

yeah, this would need to apply only to the default config, not the user-passed config.

I was thinking of always doing a check before any operation that reads from the config: normalizeConfig(), this would rename it to .json if it is .go, and just ignore if it's all ok.

Once the API and functionality has settled, then we can remove deprecated functionality.

[lcowell]

I think it's safe to close this now.

[kytrinyx]

Good catch. Thanks!