castarco

joined 1 year ago
4
submitted 9 months ago* (last edited 9 months ago) by [email protected] to c/[email protected]
 

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

Tutorial on how to create dual ESM+CJS React component libraries.

[โ€“] [email protected] 1 points 9 months ago

Thank you, I really appreciate people taking their time to read these ideas :) .

[โ€“] [email protected] 1 points 9 months ago

Hi. I think that before introducing this for bots, it should be baked in package managers in order to gain traction (this idea, or something along the same lines).

1
submitted 9 months ago* (last edited 9 months ago) by [email protected] to c/[email protected]
 

Tutorial on how to create dual ESM+CJS React component libraries.

5
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]
 

Some random ideas on NPM update policies

I'll start saying that what follows is the kind of stuff that I'm always a bit afraid to share because I mostly expect indifference or criticism, but I guess that there's no point on writing about it if it's not shared afterwards.

For a few weeks I've been thinking that, while semantic versioning is awesome, in some situations is not enough. Not everyone follows it, people break the convention accidentally, and we lack tools to manage the complexity that arises from it.

So I wrote a draft of a proposal that intends to surface some of the hidden complexity behind dependencies management to make it easier to tame, with the hope that it can help to reduce problems due to dependencies' breaking changes.

If you are interested in JavaScript or NodeJS development, I'd love to have some input from you (this also includes the criticism I always fear, as long as it's constructive ๐Ÿค“)

[โ€“] [email protected] 1 points 1 year ago* (last edited 1 year ago)

your nickname (almost) fits the question xD.

On a more serious note, not all is doom and gloom in NPM, they have improved a lot during these past years.

[โ€“] [email protected] 2 points 1 year ago

Sourcing the .env requires extra knowledge about shell scripting (even if it's basic knowledge, not everyone has it).

On the other hand, not all shells are POSIX compatible (for example, PowerShell in Windows), so if we want to make a cross-platform solution, it becomes a bit more complicated (and also requires more knowledge than the previous case).

Regarding what you commented about those incompatible "improvements", I understand what you mean, but until now I didn't find any case of this (so far, variable expansion is a native functionality of most shells nowadays).

 

For a while I've noticed that many people use dotenv in a suboptimal way, so yesterday I took the time to write a short article about better usage patterns (pretty basic stuff, so if you are an expert it's likely that you will find it boring):