WebStorm Under the Hood: How We Added Astro Support to Our IDE
Have you ever wondered how support for a new technology gets added to your favorite IDE? Well, we’ve decided to shed some light on this topic by sharing one of our most interesting recent examples of doing exactly that.
I met with WebStorm Software Developer Piotr Tomiak to get the inside story of the challenges he had to overcome to make Astro support in WebStorm a reality, while also sneaking a peek into what’s next for JetBrains’ JavaScript and TypeScript IDE.
Hi Piotr! Would you please begin by saying a few words about what Astro is and what you personally like about it?
Hi! Astro is a framework that allows you to build static websites with the possibility of incorporating dynamic content using stuff like Vue or React components and Vanilla JS. It makes heavy use of server-side rendering (SSR), which makes Astro ideal for content-heavy pages like landing pages, blog posts, and other types of static content. Additionally, users can add interactivity by using “Astro Islands”, via a process known as selective or partial hydration.
Initial Astro support landed in JetBrains IDEs in v2023.1. How and why did you make the decision to support it?
Usually, when deciding whether to support a new tool or framework, we rely on various aspects, including public statistics, comments from our users, the stability of the technology, user impact and, of course, the time required for the initial implementation and the addition of further support.
In the case of Astro, the most important criterion for us was the impact on users. Recognizing the unique syntax of Astro and the absence of any basic support based on existing TypeScript and HTML support, we understood that overlooking Astro would mean users would be unable to start adopting it. Our main goal was to achieve an adequate initial level of support so that people could start working with Astro in their side projects or even use it in production applications.
In terms of resources, implementing support for a new framework requires a lot of effort from developers and QA specialists. All told, it took almost two releases to achieve an acceptable level of Astro support.
What does it take to add support for a new framework like Astro? At what point can you say that something is supported?
If a framework, like Astro, comes with a special syntax for templates, we need to start by writing a lexer and parser. We can reuse a lot of the existing code, but there’s always some new syntax for which we need to add support. Once the component file is correctly parsed, we can start adding support for code completion, reference resolve, the Rename refactoring, and formatting.
The bare minimum for us was to provide a decent level of support for TypeScript in frontmatter and in expressions, as well as some basic code completion for Astro component names.
Can you please tell me more about how you worked on Astro support? How long did it take to add it?
Supporting Astro properly is a real challenge because its template syntax is quite unique. It took me about two weeks just to develop the lexer for it. The tricky part is that I had to start from scratch for many aspects. I initially thought I could just reuse the JSX lexer, but it turns out that Astro’s HTML parts are actual HTML code, not JSX, and that means they follow HTML’s rules, including tag omission. So, to make it work I had to create an amalgamation of HTML, TypeScript, and TSX lexers and parsers together. Making the resolve feature work within the template was also quite tricky. In regular files, scopes can be nested, but we couldn’t use the same structure here because, when the HTML template nodes are under the TypeScript frontmatter node, a lot of issues arise with TypeScript resolve. Each stage of the development process came with its own unique challenges. Overall the initial support was done in a month.
Did you manage to achieve everything you had planned in terms of Astro support for WebStorm?
I can say that the initial plan was completed and we managed to deliver support for code completion, reference resolve, the Rename refactoring, and formatting. We had originally hoped to be able to work on some of the more advanced features, too. However, in the end, providing the initial support ended up taking more time than we had anticipated, so we had to shelve these plans for the time being.
Could you please share what you are planning for the near future in terms of Astro support in WebStorm?
For now, our aim is to address the most annoying issues. We have a list of fixes in YouTrack, so you can check them all out in more detail there.
In the 2023.2 update, we’ve already tackled pre-processor support and refined its initial implementation. We’re also exploring the possibility of delivering an Astro language server, but this is still under evaluation.
User feedback is crucial to our efforts. We would therefore be very grateful if people would share their thoughts, leave comments, and vote for the most pressing tickets in our issue tracker. This input will greatly influence our focus moving forward.
And that’s it for our chat! If there’s anything else you’re curious about when it comes to WebStorm, let us know!
The WebStorm team
Subscribe to WebStorm Blog updates
