And then, we just need to check that there are any arguments left or not. If there are any, then we can keep this expression because it means that there are number arguments for this console.log call. If not, we can remove the whole expression by path.remove.
So yeah, this example is quite unrealistic. I don't think there is a real use case for console.log and types of console.log parameters. But there is a bit more practical example I've been working on with Compile Time CSS and JS library.
I've been working on library called Tidy, and the idea is that it can provide a simple functional interface with CSS function, which accepts properties like inline styles. But the idea is that instead of generating these styles in the runtime, we can compile them during the build time and extract them into the separate style sheet.
In this case, that's pretty straightforward because blue value and yellow value are static. So we can get them just from the syntax tree. But what if our code is a bit more complicated? And for example, our styles depend on the runtime. In this case, color and font-weight depend on the variant property and weight property, which are not known during the build time.
But with TypeScript, we can get the actual type of each of the properties. Like, for example, for color, we can see that it can be either violet or purple. And for font-weight, we can see that that's a union of lighter, normal, and bold values. Which makes it possible for us to go over these values and pregenerate classes for each of the value.
Thanks to the atomic representation of styles, we can compose these items in the end, just as class name composition. And all we need in the runtime is just to identify the right hash for the class name for this specific value. There is no styles generation. And again, we can benefit from styles compilation during the build time and extract it into the separate stylesheet.
If that sounds interesting to you, please check the tidy.dev website and tidy repository. It's still in a quite experimental state, but any feedback or ideas will be very much appreciated.
And in the end, just some notes. Use TSMorph for programmable interface to interact with TypeScript compiler. And you can get TypeScript type hints in Babel or any other AST traverser just from the position in the code, which is quite useful. And TypeScript integration might slow down static analysis because that's quite a lot of overhead, and it might be a good idea to apply some performance optimizations, for example, isolated into the separate worker.
There are dozens of different language server protocols. It's not just about TypeScript. So you can build a lot of different integrations as well.
And in the end, last but not least, types are not 100% trusted and they can't be because there are types like any or there are commands like TSignore. So the more attention you pay to the type safety of your codebase, the more you can benefit from it, especially during the compilation and build time. There are some useful links.
Comments