Module resolution is quite a mess in JS at the moment. With the steady move to ESM, hopefully things will get better soon. In this transition period, it's painful.
Even for those that deal with JS everyday, most don't actually understand the intricacies of CommonJS & ESM.
ESM is the biggest waste of time in the JS ecosystem. People are trying to move thing to ESM before it's even in a stable enough state. Mixing ESM and commonjs is a PITA. I've been a JS-mostly dev since 2013, and I've had enough of ESM ideologues.
I don't know why it's become this ideological war where people are 'testing the waters' on production-used libraries. It's not the approach I would have taken.
ESM _is_ the future, but not the present, and I wish people would stop foisting it on packages before its ready.
I use JS/TS every day. I tried to understand the intricacies in module/import issues. Just reading about it gave me a headache, and tempted me to just rewrite my entire project in Rust.
The compatibily issues with NodeJS dependencies (aka CommonJS modules) and ES6 modules is one of the most painful parts of Javascript today. But at the same time, I wonder if it could have been avoided. Afaik NodeJS was pioneering dependency management at the time, and all modern dependency systems (ES6, Python PipEnv, Go modules, Rust Cargo) drew inspiration from it. So it's understandable that NPM made some mistakes in the beginning
> Afaik NodeJS was pioneering dependency management at the time, and all modern dependency systems (ES6, Python PipEnv, Go modules, Rust Cargo) drew inspiration from it.
They drew a lot of inspiration from the Ruby ecosystem and its gems. It was even a lot of the same people contributing. Somehow, they ended up with a much worse tooling story, though. I think a lot of it stems from the browser/server divide they had to contend with and the worse common library.
That's funny, every time I think that I should invest a bit of time to actually learn JS, someone comes along and says "a mess in JS at the moment". I can hack something to a working state but I never feel I have a full grasp of what's happening... But I grew up on assembler 35+ years ago so all this magic is unnatural. :-)
The problem is that most devs expect agility but many modules live for 10 years+ based on whatever they were based on back in the day with no real desire to rewrite it with the latest package management thingy.
So then we end up with a mix of old and new and the promise of "moving to a bright new world" that just won't happen. As another poster said, since we know that package management is a pain, we should be able to solve all of these issues when we create a new language eco-system, not rush to get the exciting part released with "hello world" and wait for the problems to roll in later.
Interestingly, nuget as a philosophy isn't terrible but there are extreme performance issues and crazy things like not tying a package to a specific feed so if you install it, it asks all of the feeds if it has a copy, most of which will 404. Updates usually take an age but once they are installed, it usually runs OK :-)
It's the thing with every tech ever, first you need to know (way to many) intricacies, and then the tools evolve and you don't need anymore... I remember having to fight sound cards and modems on linux once, or (slightly more recent) days of having to manually install and set up every single service for local dev environment, which basically required a linux administrator level of skills from a developer, plus a lot of time and patience - and nowadays you just type a single command and drivers work, docker is up with your project ready, you're done in minutes... it's the normal path of evolution for these things...
> It's the thing with every tech ever, first you need to know (way to many) intricacies, and then the tools evolve and you don't need anymore
In an ideal world, sure. In the world of software dev tools, not always. We've regressed from Delphi and Visual Basic that allowed anyone with some data to pop up an application quickly to use that data, to the current state, which every popular language in industry (and even some unpopular ones like Rust or Haskell) make it well-nigh impossible to do very simple things.
We've gone from empowered computer users writing programs to solve their own problems to helpless computer users who cannot write programs to solve their own problems.
Sure, you may point to Excel and derivatives, but those existed back in the 90s too, and VB/Delphi existed as an intermediate point between problems that are simple enough to solve in a spreadsheet and problems that need less than a tech expert.
Maybe this is why salaries are sky-rocketing: we've collectively made everything so much harder to get into that fewer people are able to solve their own problems.
That's not how I feel, to me honestly the things got significantly easier and quicker in last 10 or so years (I primarily work in js and php now)
Sure it's not the same as it was with Delphi or VB that would install (and in case of VB also build into exe) everything you might ever need, but e.g. it's still a lot simpler than VC++ used to be back then - just figuring out all headers you need to include to compile an empty app was a horror - so it was definitely not like everything was "simple stuff" friendly back then. And doing web dev in those early days was far more complicated to setup...
Nowadays IME once you figure out how to setup the tool chain - and there's a plenty of boilerplates and starter kits for that - you more or less just rinse and repeat that every nest time. Sure sometimes package managers go berserk on you, but otherwise my experience is that - once you've figured it out - it all just magically works... but it does take some initial effort and time to figure it out properly.
And if it's really simple stuff that I need to finish quickly, I just skip the whole package managers/ build tools deal, and write a script, include and link what I need manually and run it from CLI/browser just like it's 1998 :P
Is there a steady move to ESM within the node (rather than browser) ecosystem? Because it seems that CommonJS is used for new projects by major companies.
Even for those that deal with JS everyday, most don't actually understand the intricacies of CommonJS & ESM.