Coding Week 5&6: GSoC’ 22 with SCoRe Lab
In this post, I’ll be talking about how the consequent weeks of coding went. You can read my previous post about weeks 3&4 here as well.
Now, previously we discussed a bit on the need of type-definition files and the traversal process of class ASTs, we then looked as the transformation process applied by the TypeScript compiler. This time onward, we’ll be getting a bigger picture into how exactly the plugin structure would be implemented so as to achieve a plugin that can be packaged separately and would implement all the functionality of classes obtained post transformations.
The transformed classes once obtained are pushed through the nodecloud config file, we often refer to this as the YAML file within the project as it defines the generator configuration for starting out the entire pipeline which is as follows:
- Identify relevant functions to include within the plugin, done via defining which functions to look for in the generator config file.
- Once the functions are located, parse their corresponding classes, parse the identified functions to be included as target class members and also parse relevant class attributes.
- Define the dummy class as a blueprint of the plugin class, all parsed functions are to be added into this blueprint.
- Perform the relevant transformations on the dummy class i.e. place the relevant function signatures. Function signatures are implemented into the dummy file by parsing the function parameters, JSDoc annotations, etc.
The entire pipeline above can be described conveniently by following the below procedure diagram:
Remember that the dummy Class is important here, as the final output is going to depend on the identifiers defined in a dummy class file.
Now, let’s get back to the generator config file.
The Generator config file: YAML File
The acronym for YAML is Ain’t Markup Language.
Since its debut, it has been one of the languages that are frequently used for configuration files and are very relevant in configuration specification especially within the cloud-native ecosystem.
As given above we have the generator config for specifically Kubernetes across various clouds. In a similar way, all the required functions and services across various cloud providers would be mentioned in this config file.
Once defined, the generator is ready to go and can be run by executing the following command from the generator workspace of the project.
The final expected output of the code generation process is the blueprint with complete implementations of functions from the corresponding SDK.
Epilogue 🔚
Over the course of this week, I was experimenting the correctness of the selected dummy class to get all functionalities to work. Additionally, I successfully packaged the Object Storage Module for AliCloud. Now the same is to be done for the remaining services. I’ll be working on improving the documentation of my work over the course of the next few weeks.
An interesting thing to lookout for in the coming posts would be the testing procedure of the generated classes. Also, managing workspaces in nodejs projects is not a very straightforward task and can get complicated really soon. For making this easier, we would be working with lerna, a popular workspace management.
Well, this is the end of the line for now, till next time! Follow me on my socials in case of any questions, tips, and guidance pertaining to GSoC or anything in general.
