With config_devel, when you are editing a migration, you can just enter the name of the file being edited at admin/config/config_devel
and on every request the module will check for changes and import the file into the active storage. The other direction works as well: say you are working on a contrib module and have a view. Provide the path of the file (this time in the auto export box) and on every change Drupal will automatically export. Once satisfied, just commit. Or perhaps you just want to follow what's in a config file as it's being edited -- provide sites/default/files/some.config.name.yml and it'll be right there on every save.
Both import and export are doable manually with the config module core provides. But I think the automatism makes life easier and I hope the module will be popular among D8 developers. Finally, let me thank beejeebus for cooking up the module originally and handing it over to me despite he knew I will rewrite it from the ground up.
Commenting on this Story is closed.
So what is the difference between beejeebus's config_devel and your rewritten config_devel?
One common feature is the ability to write configuration back. However, his used settings; I am using CMI to specify what to write back allowing for an easy UI.
His also was functioning, sort of, to provide config-as-files but it was not doing proper config import. Also, it was exposing every config as a file (if configured with a directory) which is not necessary IMO, just created clutter.
In short, his was more along the lines of "what can config do" while mine is more along the lines of "what developers want to do". I have, so far, identified two very common scenarios (editing a migration in an editor and editing a view/block/etc in the UI) and built the module corresponding to those.