I’m looking at writing a package that provides a gui interface for viewing and modifying a project-level tsconfig.json file. This led me to look for a more general solution for editing any and all json configuration files, one that relies upon some kind of schema to prevent invalid values. When I read the documentation for the core Config class and realized that Atom already has some similar functionality in the form of package configurations, I thought I had found the perfect solution.
Not so much.
After reading through the CoffeeScript source for the SettingsPanel class, I realized that it was very tightly coupled to the atom.config object. Is there any reason why this could not or should not be changed? If the settings panel class was made available as a general solution for generating simple forms declaratively, then not only would my work be half done, it would open up a whole realm of possibilities for other json-based configuration files, including Atom package manifest files.
P.S. First thoughts on CoffeeScript is that the syntax is a bit complicated in that there are so many different basic constructs. It’s like the evil twin of LISP. At this point, I am withholding further judgment, though.