Lack of a professional IDE / tooling ecosystem for MicroPython

[MrCorsair3]

I would like to raise a concern regarding the current state of development tooling for MicroPython.

At the moment, the only commonly recommended IDE is Thonny with MicroPython support. While it is useful for beginners and education, it does not feel like a professional-grade IDE suitable for larger or long-term projects.

In the case of VS Code, there is no well-maintained, official, or widely accepted extension for MicroPython. Most available extensions appear to be:

• unmaintained,

• very limited in functionality,

• focused on specific vendors (e.g. LEGO),

• or unsuitable for serious development (lack of proper code completion, project management, testing, deployment workflows, etc.).

This raises a broader question:
Isn’t the lack of a solid, professional development environment a major obstacle for using MicroPython as anything more than a hobby, educational tool, or curiosity?

I am also genuinely curious how teams that use MicroPython in production handle this:

• What does your development environment look like?

• Do you write code in basic text editors or plain .py files without proper IDE support?

• How do you manage larger codebases, refactoring, testing, and deployment?

It feels like tooling is currently one of the biggest barriers to wider adoption of MicroPython in serious projects, and I would appreciate hearing the maintainers’ and community’s perspective on this.

[sosi-deadeye]

Isn’t the lack of a solid, professional development environment a major obstacle for using

Yes, it is. Check out the prices of the major manufacturers. Some IDEs are free, but then cost something if you need additional features.

I use only MicroPython, because I use Python since version 2.6. So I don't need an IDE, I need good documentation.

I think one important part is this: https://micropython-stubs.readthedocs.io/en/main/
With TypeHints you can use any IDE which supports it.

[Josverl]

VSCode and Pycharm are recognised as best in class IDEs
Both have really good support for Python, and thus with just a little help also for MicroPython, either through configuration, or through add-ins / Extensions such as:

• https://github.com/lukaskremla/micropython-tools-jetbrains
• https://github.com/paulober/MicroPico

Both include the settings and port, or board, or custom typestubs that in my opinion (might be biased here) allow both developers, (and their AI agents if they desire) to transition easily from CPython to MicroPython.

Add the MicroPython repl to that, and that saves you a 2 minute Edit, compile, link, flash, reboot, test cycle for exploratory testing, often replacing it with just typing an expression

As always in IT land, there are many things that could be even better.

[karfas]

Isn’t the lack of a solid, professional development environment a major obstacle for using

Yes, it is. Check out the prices of the major manufacturers. Some IDEs are free, but then cost something if you need additional features.

I don't buy this argument. Even with the "best" IDE under the sun (define "best" - for which use case ?) Micropython will not achieve world dominance :-).
When designing/developing embedded systems, cost and company policies are major factors. I think that Micropython, with it's requirement for hundreds of kB memory and limited real-time performance, has a niche too small to be interesting for major companies. What is the per-unit cost factor for thousands of devices when you save 10% development time due to a slightly better IDE ?

[Josverl]

I don't buy this

You do not need to, an IDE is just a tool to use,
And actually (some of) the best are free:
https://www.devopsschool.com/blog/top-10-integrated-development-environments-ides-tools-in-2025-features-pros-cons-comparison/

Also human labor is massively more expensive than any amount of silicon, so that should added in as well.

Most large software companies use a very conscious mix of languages to avoid the complexity of microcode, C/C++ as much as possible. Not because it is not fast and efficient to run, but because it is expensive and error-prone to maintain and update. if you look at the major popular languages of recent years, several have been actually designed to help reduce that.

No single language or co-system will tick all everyone's boxes for any project on any scale.
But neither does that disqualify such a language or eco-system.

MicroPython will not achieve world dominance

I don't think that is on the charter fortunately

[drwheeler]

As josverl describes: My workflow for MicroPython development using VSCode on linux seems to work OK for me - minus single stepping debugging which I doubt would work well anyway since I tend to use a lot of asyncio tasks.

VSCode extensions: python and pylance
Virtual env in project folder for typings, mpremote and mpy-cross
mpremote local . so that I don't wear out the flash, loads into RAM from the project folder. This can be slow for big projects so mpy-cross compile the 'finished' files to make them smaller and not have MicroPython compile them each time. Need to move the original .py source somewhere else though.

'/' in the MicroPython filesystem contains dummy boot.py and main.py, or just nothing most of the time during development.

In the REPL ( from mpremote local . ):

while True:
    Save changes in VSCode.
    Ctrl-C
    Ctrl-D 
    import boot
    import main
    watch it run, fix the failures

[Hristo-Nikodimov-Nenkov]

I use VS Code with MicroPico, Python and Pylance and it works well for both rp2 and esp32 boards.
You just need to configure it once and after that copy the .vscode directory to the new project.
Look here

[easytarget]

For educational and hobby use thonny is a excellent IDE; handles some of the basics nicely while having basic functionality. It has no pretentions of competing with IDE ecosystems like VS etc, but has probably helped more beginners learn how to use an IDE and program in micropython than VS ever has.

If you want something a bit more 'mid level' try Viper IDE, it is web based and even runs well on my phone.

For hight-end IDE's you have VS and co.

Personally I use vim on the commandline in one or more terminals, and test on the devboard with:
$ mpremote mount . repl --inject-code "import my_main_file"

If I am not doing hardware specific stuff I often run my code in the unix micropython port to test without needing a devboard.

[Hristo-Nikodimov-Nenkov]

At the moment it is not that difficult, just:
pip install -U micropython-[-]-stubs==<micropython_version> --no-user
and "python.analysis.extraPaths": [
"micropython-esp32-esp32_generic_c3-stubs-1.27.0.post1",
... ]
in .vscode/settings.json
where <board> is for example esp32_generic_c3 ( same as in ports/<port>/boards, but lower-case).

That was the idea for this repo, to make building custom firmwares easy and automated.

[Josverl]

Full explanation for 'the stubs'

https://micropython-stubs.readthedocs.io/en/main/22_vscode.html

I recommend to also configuring the std lib overrides for MicroPython

https://micropython-stubs.readthedocs.io/en/main/22_vscode.html#vscode-configure-pylance-to-read-micropython-stdlib-stubs

I've actually been looking at options to integrate an LSP into Thonny or ViperIDE to improve their type checking abilities. I have only found that possible with a server component, not purely client or wasm hosted.
Perhaps that is another side project to revive...

A small request:
The MicroPython stubs are not perfect, yet..., I try to make them not wrong, not raise type errors unless ...

But if you find that something is not right, or could be improved, please let me know by raising an issue, then I'll look into fixing it for everyone.

[Hristo-Nikodimov-Nenkov]

Where should I post some issues?

In micropython-esp32-esp32_generic_c3-stubs-1.27.0.post1

from uasyncio import sleep_ms
from usys import print_exception
from uos import mount, umount, statvfs

[Josverl]

Please feel free to create an issue in the stubs repo: https://github.com/Josverl/micropython-stubs/issues/new.

a few suggestions based on the above snippet.

• if you see unexpected errors on stdlib modules; you may not have properly configured vscode for the use of the micropython-stdlib-stubs
• you should drop the u prefix from the stdlib modules in your code.

  https://docs.micropython.org/en/latest/library/index.html#extending-built-in-libraries-from-python
  Other than when it specifically needs to force the use of the built-in module, code should always use import module rather than import umodule.

• the mount and umount methods have moved to the vfs module. Use from vfs import mount, umount

  The function "mount" is deprecated
  The mount function is deprecated, use vfs.mount instead.

[Hristo-Nikodimov-Nenkov]

Thanks.
I'll implement the changes you suggested and I'll open issue if there are any warnings left.

[DanielBustillos]

I’ve been feeling this exact "tooling gap" for a while. I love Thonny’s simplicity, but for professional work, I really need the advanced IntelliSense, stubs, and Git integration that VS Code offers.

That’s why I started building MPY Workbench. It's still in development, but I’m already using it for my own professional projects to keep things in sync between my workspace and the board without the manual overhead.

I'm trying to stay on top of issues and feedback to make it as solid as possible. If you have a chance to try it out, I’d love to hear if it solves those friction points for you 🚀