Another couple of weeks have passed. Unfortunately, there isn’t a lot to share like last time when I tackled big and unrelated issues. But I still hope you take away something from this post!
Note: This is my 3rd Bi-Weekly blog. You can find the rest of them here
As always, here’s the list of PRs that I made during these past two weeks.
Issue(s) | Description | Pull Request | Status |
---|---|---|---|
- | Upgrading to yarn 3 | #5022 | Merged |
- | Converting campaigns lists to JSX | #5026 | Merged |
And now, let’s go into a bit more detail.
Yarn is a package manager for the JavaScript programming language, just like npm. Unfortunately, Yarn has two major versions, and we were using the older one - yarn classic.
Yarn modern offers a lot of new features. The most important of them is Plug and Play mode, which gets rid of the node modules folder. Unfortunately, it’s also the one that causes the most pain when migrating from classic to modern. For example, some packages aren’t compatible with PnP since they expect the presence of a node_modules folder.
More importantly for us though, PnP mode also requires a bit of configuration on the developer’s side. Without configuring your editor correctly, you’ll not get niceties like autocomplete, IntelliSense, etc
Fortunately, it’s easy enough to disable PnP and it is certainly better than continuing to use yarn classic.
Another issue we had to deal with was how to install yarn
. The modern way is to use Corepack. Corepack enables you to use the package manager of your choice without installing it first. This is the way npm
works and with Corepack, you can similarly use yarn
(or pnpm
) without installing them. It also ensures that each developer has the same version of the package manager(via the packageManager
field in package.json
)
But since Corepack is still experimental and has to be enabled manually, the GitHub action we use to set up our node environment doesn’t support it
Until that changes, it’s just easier to bundle in the yarn
binary in the repo itself so that everyone uses the same version of it.
We have a lot of lists/tables on the site. Unfortunately, they’re not React components. Instead, they are rendered on the server. This also means that we have to use a third-party library - list.js - to sort the lists based on user interaction. We use a fork of it, so there’s even more reason to migrate to React.
And that’s what I’ve been doing. Writing a list component isn’t that difficult but writing one that can be used for multiple lists(ie, is generic) is a bit of a challenge. Since there are a lot of server-rendered lists, writing a different component for each of them is virtually impossible.
And I think I’ve mostly been successful. I’ve been able to convert 4 of the lists to React components so far. This also means that page loads are a bit faster - we don’t have to wait for the server to the data fetch from the database and render the lists - all of that happens after the page has already loaded.
I’ve taken more time than I expected to get these lists converted to React components. There are still quite a few lists left to convert, but now that I’ve got a better idea of how all this works, I can do it much quicker.
And that’s what I intend to do next. If I have time, I’ll also try to start my work on migrating away from Moment JS. That’s another huge endeavor but certainly worth it.
And that’s all for now. Hope to see you again!