The Elm plugin for IntelliJ has had advanced support for renaming functions, types and modules for almost 2 years now. But until version 3.4.0, it couldn’t rename record fields. It’s difficult to get this right because you don’t want to accidentaly rename a record which has a field of the same name but is actually independent. I’m happy to announce that we are now able to do this reliably, and that you can now:
rename record fields
go to a record field’s declaration
find all usages of a record field
I’m really excited about this feature and all of the other stuff that we’ve added this year (generate JSON decoders & encoders!), so I figured I would record a demo video showing off the latest features.
The video covers:
rename refactoring
unused import detection
unused code detection
auto add import
type inference of expressions
generate type annotations
generate JSON decoders and encoders
‘introduce variable’ refactoring (extract expr into a let/in)
A tip to anyone that gets lots of “unresolved reference” errors after upgrading:
Run the “Invalidate Caches / Restart” action in IntelliJ, that fixed it for me
Great video, thanks so much for the hard work from all involved! the Codec generation in particular looks like it will be a huge help.
One piece of feedback is that configuring the IntelliJ plugin is inconvenient if you don’t want to globally install node/elm etc. AFAICT IntelliJ assumes you have a single globally installed node and that the elm* commands are set up the same way.
If I’ve a .nvmrc file in the root of the project it’d be great if IntelliJ could use that when running the various elm* commands. The plugin will try to discover the paths, but I don’t think it can use nvm to set up the path to enable this. Even without .nvmrc support, if I could specify the nvm version to use through another mechanism that would be good enough.
Hard-coding the binary’s nvm-sandboxed path into the plugin configuration works for some commands, but even then commands that also depend on node (e.g. elm-test) will still fail without a globally available node.
@adamnfish I would love to add proper support for nvm. I personally don’t use nvm, so it was difficult for me to know what the ideal solution would be.
Having the plugin read the .nvmrc file sounds like the way to go. Can you create an issue on Github with more details? e.g. a representative .nvmrc file along with how you would expect it to work with the paths to elm, elm-format, and elm-test. Thanks.
@adamnfish@klazuka Instead of nvm I suggest you to give a look at asdf-vm. It is like nvm, but not only for node.js, but for more than 100 applications like elixir, bash, postgresql, erlang… (plugin-list). You also have the .nvmrc equivalent, which is called .tool-versions. IMHO, existing asdf, nvm doesn’t make much sense.
