I have released the v1.0.0 version of es6_maps!

The major changes are:

• es6_maps now amends the Elixir compiler at a different point (:elixir.string_to_tokens/5), which improves compatibility with other Elixir tools and happens to be a more stable API.
• It can now be used at runtime, so we can paste in shorthand syntax to deployed shells
• It includes an ElixirLS plugin to ensure it’s active while the language server analyzes the code.

The v1.0.0 is also meant to signal production readiness. The library has been battle tested over the past year, and with the changes above I’m confident of its stability going forward.

GitHub: GitHub - kzemek/es6_maps: ES6-like shorthand syntax for Elixir maps: `%{foo, bar} = map; IO.puts(foo)`
Hex: es6_maps | Hex
HexDocs: es6_maps v1.0.0 — Documentation

This discussion is at least as old as elixir is stable. This is from just a few month after 1.0 and it still mentions earlier proposals as well: https://groups.google.com/g/elixir-lang-core/c/NoUo2gqQR3I

I believe this is the most recent extended discussion complete with proposal and poll: https://forum.elixirforum.net/t/proposal-add-field-puns-map-shorthand-to-elixir/15452

Is there a reason why you have created a custom mix task for formatting instead of writing a plugin for .formatter.exs file?

A couple:

• It’s very hard to pass-through formatting when implementing Mix.Tasks.Format behaviour. If your plugin says it handles [".ex", ".exs"] extensions, it will take over these extensions completely, and the original formatter won’t run anymore.
  In its initial incarnation the formatter only concerned itself with maps, leaving the rest of the formatting up to the default formatter. It’s true that the current version basically does the whole format though, calling Mix.Format just in case…
• But more importantly, I included a formatting task as a way to jump all-in, but primarily as a guarantee for people that they’ll be able to jump out if needed. I did see that as a one-off, explicitly called task.

That said, with the current implementation it might make sense to both have the task and an optional formatter for people to use, sharing the same code.

Could you please add some kind of verification to the compile task (with special form maybe?), so the code would not fail in said task and it would automatically call --revert and print a warning instead? Is it possible in this case?

It is possible, but I don’t think I can sensibly guard / detect against incompatible changes in the compiler without knowing what the changes would be. Also note that es6_maps only modifies the compiler that runs in a separate pass, it doesn’t compile things by itself.

To be clear, if I could detect that the code would fail to compile due to the shorthand-form maps I wouldn’t reformat user’s on-disk files anyway – and, if I found a good way to modify AST and pass it to the compiler, I would have rewritten the whole library to use that mechanism instead and there wouldn’t be a need for a fallback in the first place.

Is there a reason why you have created a custom mix task for formatting instead of writing a plugin for .formatter.exs file?

Following our discussion, I have just released v0.2.2 where the custom format task is replaced with a formatting plugin that can be additionally configured inline with comment pragmas.