Newsletter #7 - Node modules

Sébastien Dubois / May 06, 2020

4 min read

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: https://mailchi.mp/fb661753d54a/developassion-newsletter

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.

Gitlab VS node_modules

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...

Using stable versions of node/npm/yarn

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

TypeScript 3.9 incoming

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.

TypeScript articles

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

Writing good and useful code comments

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! :)

That's all folks!

I'm really interested to hear about what you think of this newsletter. If you have remarks, ideas/articles to share, then please don't hesitate to contact me through Twitter (https://twitter.com/dSebastien). DMs are open.

If you find this newsletter interesting, then please share the link around: https://mailchi.mp/fb661753d54a/developassion-newsletter

See you next time!

PS: check out my Dev Concepts books, join the Software Crafters community, the Personal Knowledge Management community, and come say hi on Twitter!
Discuss on TwitterEdit on GitHub