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
For more information, see https://github.com/klazuka/intellij-elm. If you have questions, DM me on Slack.
Awesome! It would be really cool if you find some time and record a small video about build process setup for novices in elm & idea.
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
@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.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.