philnash

joined 2 years ago
 

cross-posted from: https://programming.dev/post/11927506

Many times when I’ve tried to write some code in Node.js using ES modules I’ve found myself reaching for __dirname and then looking up how to replace it. Now Node.js, Deno and Bun support import.meta.dirname. Check out the article for more detail.

 

Many times when I’ve tried to write some code in Node.js using ES modules I’ve found myself reaching for __dirname and then looking up how to replace it. Now Node.js, Deno and Bun support import.meta.dirname. Check out the article for more detail.

[–] philnash 2 points 1 year ago

That’s brilliant!

[–] philnash 5 points 1 year ago (2 children)

JavaScript's regex engine isn't the only one to have these problems. There certainly are other implementations, like Re2 and Rust's implementation, that don't have this issue. But they also lack some of the features of the JS implementation too.

[–] philnash 6 points 1 year ago

While this article is about JavaScript specifically, these issues certainly exist in other regex engines too.

[–] philnash 4 points 1 year ago

Ah, I didn’t realise there was a regex channel here. Thanks!

[–] philnash 3 points 1 year ago

The only real way to validate an email address is send it an email and see if it arrives! I'm sure many of us have fallen to the urge to validate an email with a regex though, and yes, it's just too dangerous! I definitely like the simplicity of checking for an @.

I think regular expressions are actually very tempting to use because they seem hard. I feel like I go through this XKCD comic every time the opportunity to use a regex comes up. But string functions often have the answer. I hope, if this article achieves anything, it just stops people using regex to trim whitespace!

[–] philnash 2 points 1 year ago
17
submitted 1 year ago* (last edited 1 year ago) by philnash to c/typescript
 

Click bait title, but this post goes into depth about using tsconfig.json correctly and across different layers of your project.

[–] philnash 1 points 1 year ago

I think you're absolutely right about the difficulty for developers inadvertently getting the legacy assert behaviour. Though I hope if they do that, they at least recognise that they can use the strict methods.

The early module had both non-strict and strict methods, even from that early time, so the original author recognised the need for using ===, but I guess wanted to be flexible and allow for == usage too. Perhaps this was a bad decision, but it was made in version 0.1.21, so I would guess there was a lot of fast work going on with Node at the time and maybe not everything was thought through in as much depth as it could be. It's possible that one day the strict module may take over the place of the existing assert module, but that would be quite the breaking change!

view more: next ›