DEV Community: jkorichneva

Is your PR really ready for review?

jkorichneva — Fri, 26 May 2023 10:29:15 +0000

When it comes to writing code, it's not just about making it work - it's also about making it readable and maintainable. Even though code review is a common practice, it is still a time-consuming and sometimes tiring process. It's important to reduce the amount of time needed for review and to make it easier for your colleagues. This way you have better chances for quick merge 🙂

One effective way to do this is by checking your own PRs before asking for a review. But what exactly should you be checking in order to save everyone's time?

While there are numerous articles and checklists on this topic, most of them cover common issues that can be fixed automatically, like alphabetical sorting of imports, typos and etc. Instead, this checklist focuses on aspects that cannot be automated:

Variable names are clear and descriptive.
Comments are added where necessary to clarify your changes.
There are no out-of-scope changes in the PR.
PR focuses on one feature and is relatively small.
All functions and variables are in the right files and that there are no misplaced elements.
There is a description of the PR to give reviewers context.
Docs are updated to reflect any changes made in the PR.
Any necessary cleanups are done.
Follow the single responsibility principle in functions.
Keep consistency in mind throughout the PR.
Follow the boyscout rule: 'Always leave the code better than you found it.'

If you check whether your PR complies with these rules, you will definitely get less comments on Code Review and save your colleagues a lot of time🙌

How I re-wrote all my composite actions to workflows and why

jkorichneva — Wed, 24 May 2023 16:54:35 +0000

What are composite actions and workflows?

For one of my projects I used Github Actions for our CI/CD, which provided me with two fundamental ways of organizing our pipeline code - workflows and actions. What's the difference between them?

A workflow is a configurable automated process that will run one or more jobs.

A composite action allows you to combine multiple workflow steps within one action.

In general, both approaches allow you to create reusable pipeline code, following the DRY (Do not repeat yourself) principle and combine related actions into one flow. From these quotes it is hard to determine which approach you should choose. If you want to get a quick overview - feel free to jump down to summary in a table and conclusion. Meanwhile, we will take a closer look.

Let's take create a composite action and reusable workflow, then investigate the differences:

You can copy these snippets or fork my repo. Let's run the trigger workflow from main branch:

Storage and folder structure

Storage and folder structure differ for the two approaches. When using a composite action, you need to create a separate folder, and the action file must always be named action.yml. On the other hand, workflows can be named freely and stored in the workflows folder.

If you aim to make actions or workflows reusable across multiple repositories, you have the option to publish them publicly. This allows other users to leverage your actions or workflows. However, if you have a Github Enterprise plan, you can create a private repository specifically for reusable actions or workflows, which will be shared only within your organization. This provides a more controlled and restricted sharing mechanism.

Calling

We call a composite action as a step inside a job and we should always checkout from repo, otherwise there will be an error.
When we call a reusable workflow, we "replace" the job in a workflow with this workflow and there is no need to check out.

Secret management

Reusable workflows can inherit secrets from caller workflow, also github context is shared between them. If you want to use secrets in composite action, you have to pass them as inputs or ENV-variables.

Jobs and paralleling

You can parallel jobs in a reusable workflow, but you can parallel steps in a composite action. Composite action is a sequence of steps and can't use jobs inside.

Logging and timing

Github Actions' interface shows you the sequence of steps executed and their timing. If you are using a resuable workflow, each step inside workflow is timed a displayed separately:

Composite action is timed and displayed as one step, making tracking of pipeline's performance harder:

If you put importance in maintaining quick and transparent pipeline execution, this difference might be vital for you, as it was for me.

My story

When I started refactoring the pipelines, I switched to composite actions, because mostly the code I extracted seemed to be like a complex step, rather then a job. Since the project's frontend resided in a monorepo, pipeline timing was an important metric. As the codebase grew with more applications, I encountered an issue when our pipeline execution time exceeded a critical threshold of eight minutes and started investigating, where the bottleneck was.

As I dived into logs, Iunderstood, that wrapping steps into composite actions was a mistake. It was impossible to understand what is taking longer, unit tests or build time, when they are both timed as one step.

I rewrote everything that was vital for timing and now I have a better understanding of where there is room for improvement in our pipeline because we are timing and collecting the stats for each step. There still are some composite actions, but they combine only lightweight steps.

Summing up the differences:

Conclusion

In general, both reusable workflows and composite actions provide pretty much the same functionality. The main difference is in logging output, secret management and syntax, that you should keep in mind. If you know, that your pipeline might become a bottleneck you will need to improve, then go with reusable workflows for heavy tasks.

Migrating single-spa monorepo to Vite with minimal changes in PR

jkorichneva — Sat, 22 Apr 2023 09:22:21 +0000

I have been with webpack for quite a long time, starting with version 3, then 4, and finally 5. It is familiar and incredibly customizable. Nevertheless, when you have to wait about 30 seconds to get your build done and then about 5 seconds for your changes to become interactive, love for webpack slowly vanishes.

Usually there are three ways to deal with this tiring waiting:

Optimize webpack to make it faster (e.g. try lazy compilation)
Reduce bundle size (webpack-bundle-analyzer is useful for this)
Look for an alternative solution

While I tried the second option, it didn't fully solve the issue. Vite has long been on everybody’s lips, promising quick builds and almost instant HMR. I decided to experiment with our single-spa monorepo and see the results.

About migration
There are many migration guides available online, so I won't repeat them here,as they are easy to find. Generally, these are the steps to follow:

Install the necessary packages.
Introduce an index.html file in the root folder.
Add the Vite config and customize it for your build.
Change the commands to use Vite.

While going through these steps, I encountered following issues in adapting my configs of build into vite:

Env-variables
Vite requires all env variables to have the VITE_ prefix, but changing all references would have resulted in a large PR that would be difficult to review. I found a solution in vite-plugin-environment, which allowed me to keep all process.env references untouched

Absolute ts imports
Many of our imports, like lib/exampleHook, were broken after switching to Vite. The issue was resolved just by adding vite-tsconfig-paths and all started working.

License generation
Webpack creates license files out-of-the-box, while rollup that is inside vite, doesn’t. This can be fixed by rollup-plugin-license, it has a lot of customization, but in the end, I found the text files not so fancy as webpack. Maybe I just did not get it right.

Npm-package, that is not a module
We used single-spa-html module for displaying some static errors, that was not a module, but a IIFE inside. I had to fork it and to put it inside my repo, changing it into a module.

Single-spa complications
When developing locally, we loaded some scripts from test environment, that are transpiled into commonjs and that was a complication, as local modules should have been handled by vite, whereas those modules had to be registered via System Js. It lead to ugly if else that I won’t even add here.

Another issue was that we had a module, that was used by all others externally. And again, the modules from test env needed commonjs version of sdk, while local needed es6 version, which also lead to pre-building it and serving from dist. I tried various configs, but didn’t succeed — vite was unstable when loading it and that sometimes affected the performance of the whole application.

Results with vite actually working:

Local startup was about 30s, with vite about 3–4 seconds
CI build time decreased by 30 seconds
HMR was almost instant

Conclusion
Vite is great, it really is a silver bullet for apps that take a long time building. However, if you have already codebase with customizations, the migration can be painful. As vite was working unstable with our external module and this issue required a lot of investigation, we decided to postpone the migration for now. Hopefully, after some other refactoring, we will get back to it.