DeveloPassion's Newsletter #7 - Node module

Welcome to the seventh edition of DeveloPassion’s newsletter. Before we start, I’d like to ask all of you to help me out a bit. If you find this newsletter interesting, then please do take a bit of time to share this link to others on social media: With your help, others will also get a chance to discover and enjoy reading it. As an added benefit, it’ll also motivate me to continue the experience! Don’t forget that you can also follow me on Twitter and Medium where i publish my articles.

As unsettling as this may be, Gitlab is not really on par with other CI/CD systems for projects using node (whether with npm or yarn). This was a bit of a surprise for me. I found Gitlab to be muuuuuch slower than Travis, CircleCI and others for handling my node_modules folders between pipeline executions / jobs. I’ve tried setting up my CI/CD pipeline on Gitlab to use the officially recommended caching mechanism, but it just made things worse. So a few weeks back, I set out to improve things a bit, and finally reached a more acceptable status. I’ve posted an article about this, explaining the things I’ve tried and the steps I’ve taken: https://medium.com/@dSebastien/speeding-up-your-ci-cd-build-times-with-a-custom-docker-image-3bfaac4e0479 Note that I think that Yarn 2 is probably even faster now; I’ll have to give it a try…

I’ve published an article explaining why and how to stabilize the versions of node and npm/yarn in a project. It’s something that I did early on in my project and that I really don’t regret: https://medium.com/@dSebastien/why-and-how-to-use-stable-node-and-npm-versions-across-your-project-team-a4886f51a96c The major benefit for me is the confidence that everything runs in the same way on my machine, on my colleagues machines, in acceptance and in production. By putting this in place early on, you’ll spare yourself some trouble. As a follow up, Kiril has continued the investigations using Yarn, which is also interesting: https://medium.com/disdj/speed-up-npm-yarn-install-in-gitlab-1434437f9857

Another month confined, another incoming TypeScript release. I’ve published an overview of the upcoming features: https://medium.com/javascript-in-plain-english/the-coolest-improvements-coming-with-typescript-3-9-90977bd73a24 The main improvement this time is SPEED, which is certainly going to feel great for large projects. Another one is the new @ts-expect-error suppression comment, which is valuable for testing and TS libraries consumed by JS code.

While we’re onto TypeScript, I’ve published two new articles this week. The first one is a tip for monorepos and how to better configure your IDE to generate more intelligen (i.e., not broken) import statements: https://medium.com/javascript-in-plain-english/avoiding-import-issues-in-typescript-monorepos-d5a4b21f90ef The second one is a piece I wrote about in my book: TypeScript non-goals. People often write and explain about what TypeScript does, but knowing about what it doesn’t want to do is also interesting. To me, the non-goals of TypeScript are really important, as they define a sort of “moral compass” for the TypeScript project: https://medium.com/javascript-in-plain-english/typescript-non-goals-43f47c1ecd84

Each time that I dive into someone else’s code, I can’t help but useless comments, commented out code and plain wrong/misleading ones. I sometimes feel like i’m the only one who truly cares about the importance of keeping codebases nice and tidy. Of course, with time pressure, it’s hard to keep everything nice and clean, but with some motivation, it’s not that hard to keep our codebase cleaner. I’ve shared a few of my ideas about code comments, explaining what to avoid and what to do: https://itnext.io/how-to-write-code-comments-like-a-pro-c830e68cec92 For instance, I tend to prefer writing log statements than explanation comments. I also strongly disapprove commenting out code; source control management software exist for a reason! Anyways, go read the article and write better code… comments! :)