Hello!
A few months ago, we announced a developer experience survey to give you an opportunity to voice your suggestions for our short term (one-year) priorities for the Motoko language ecosystem.
Since then, I’ve systematically addressed many of the most frequent requests, especially those involving the Motoko VS Code extension.
Here’s a quick overview of the main improvements since releasing the survey:
Available Now
-
Automatic imports: Easily import files from the base library, Vessel packages, and your local workspace using a “quick fix” code action.
-
Multi-canister development: Instead of having to manually choose one canister to work on at a time, it’s finally possible to work on everything in your project without restarting the language server. You’ll also be able to use “
canister:” imports after running “dfx deploy” in your terminal. -
Code formatter: The Motoko extension now supports prettier-plugin-motoko out of the box. It’s easy to format your Motoko file on save and/or customize the formatter to your heart’s content using a .prettierrc file.
-
Type information: Quickly view the type signature of almost any part of a Motoko program by hovering with your mouse cursor.
-
Syntax highlighting: The extension’s code highlighter is now fully up-to-date, making it easier to understand Motoko programs at a glance.
-
Autocompletion: It is now much more convenient to reference both local variables and importable modules. You can also expect further improvements to autocompletion as we continue building out a brand new language server for the extension.
-
Windows support: Thanks to a new language server which no longer relies on having
dfxinstalled on your computer, the extension is now fully functional on Windows (even without WSL).
All of these improvements are available for
dfxversions0.11.2and above.
Make sure to check yourdfx.jsonfile in case a previous version is specified.
Work in Progress
-
Built-in documentation: We are starting to add informational tooltips for language features, error messages, and anywhere a quick, simple explanation could save a few minutes of everyone’s time. Let me know if you have any suggestions for built-in Motoko documentation.
-
Organize imports: This is a highly requested feature, and I want to ensure that most people will be happy with the default behavior. Let me know if you have any strong preferences for how this should work!
-
Go-to-definition: This IDE feature is a massive productivity booster, so I’m setting the groundwork for Motoko source code navigation to eventually feel as intuitive as with other languages in VS Code.
If you encounter any bugs or unexpected behavior, let us know by submitting an issue on the dfinity/vscode-motoko GitHub repository. Thanks!
Opportunities
Now that we’re covering the basics, I look forward to exploring a few ideas that would give Motoko some additional competitive advantages for developing Web3 applications.
-
“Motoko Dev Server”: We are in the early stages of creating a rapid prototyping workflow for Motoko canisters. You can think of this as a smart contract equivalent of the hot-reload functionality in create-react-app, Ruby on Rails, Flutter, and other development workflows with an emphasis on blazing-fast feedback loops between your editor and application.
-
Unit testing: Nothing is more satisfying (and important for high-value software) than making a change to a codebase and seeing hundreds of green check marks indicating successful unit tests. I am planning to eventually overhaul Motoko unit testing using the capabilities offered by VS Code and other modern IDEs.
Thanks for reading!
In case you missed it, I strongly encourage you to take the Motoko Developer Experience Survey. We are still looking through every single response, and the results are directly used to prioritize new features and improvements.
Let me know if you have any burning questions, pain points, or suggestions around the VS Code extension or anything else in the Motoko ecosystem.
Cheers!
~ Ryan