Today’s JavaScript, from an outsider’s perspective (2020)
1–10 of 391 posts
Re: Today’s JavaScript, from an outsider’s perspective (2020)
#2All he had to do was run `node index.mjs` or `npm run start` to have his index recognized as a module.
Node DOES not read package.json, npm (node package manager) does. Node is not the package manager, so of course changes to package.json won't affect running `node index.js`
However, node recognizes the file extension mjs as a module and will execute it as such. So renaming the extension of the script would work.
Alternatively, if you wish to use the package.json info to launch node, use the package manager through `npm run start`
This isn't rocket science and honestly makes perfect sense.
Package management is basic stuff and Node really doesn't do it any different than Ruby gems or Pip requirements, etc..I think you and your buddy need to have a talk about the assumptions you're making with regard to the actual executable versus the package manager and re- evaluate your understanding from first principles.
Re: Today’s JavaScript, from an outsider’s perspective (2020)
#3All he had to do was run `node index.mjs` or `npm run start` to have his index recognized as a module. Node DOES not read package.json, npm (node package manager) does. Node is not the package manager, so of course changes to package.json won't affect running `node index.js` However, node recognizes the file extension mjs as a module and will execute it as such. So renaming the extension of the script would work. Alt…
It only makes sense because you understand the decisions behind it. Try teaching JS to someone with little experience — they don’t care that the browser wants one kind of module and Node wants another. They don’t know what a module is, they just want their code to run
Re: Today’s JavaScript, from an outsider’s perspective (2020)
#4Chances are, the only thing interesting from that package is a single source file, which you could just copy over to your project.
Re: Today’s JavaScript, from an outsider’s perspective (2020)
#5Deno uses ES modules and has a build in TypeScript compiler and solves these issues. Just be careful when using different versions of different packages and always use the same version of a service like esm.sh that translates CommonJS modules to ES modules, it has a versioned API so esm.sh/v70/lodash@1.2 != esm.sh/v71/lodash@1.2. I hit my head on this problem for a couple of days.
Re: Today’s JavaScript, from an outsider’s perspective (2020)
#6All he had to do was run `node index.mjs` or `npm run start` to have his index recognized as a module. Node DOES not read package.json, npm (node package manager) does. Node is not the package manager, so of course changes to package.json won't affect running `node index.js` However, node recognizes the file extension mjs as a module and will execute it as such. So renaming the extension of the script would work. Alt…
> This isn't rocket science and honestly makes perfect sense.
it only makes sense if you understand all the differences between ES modules and node modules that exists purely for historical reasons. Node modules are not part of ES specification at first place.
Re: Today’s JavaScript, from an outsider’s perspective (2020)
#7All he had to do was run `node index.mjs` or `npm run start` to have his index recognized as a module. Node DOES not read package.json, npm (node package manager) does. Node is not the package manager, so of course changes to package.json won't affect running `node index.js` However, node recognizes the file extension mjs as a module and will execute it as such. So renaming the extension of the script would work. Alt…
Can't tell if you're being sarcastic or needlessly abrasive. Anyway, it doesn't really matter how supposedly intuitive something is if the actual experience of using it results in the pain expressed by the author's friend. It's called usability because it's about the user. FWIW I've been writing JS for 12+ years and I resonate a lot with the post. Taking random error strings and plugging them into google often takes you on a long winding path of hair-pulling until you eventually give up. It's painful. Anyone who thinks it's painless should reflect on where they sit on the dunning-kruger distribution.
The JS eco-system is in a very elongated (and necessary) growth phase, and right now it's still incredibly hard to "just make things work" if you're starting out. With each year that passes it gets more complicated. Having a fundamental understanding of it all becomes less possible; one must pick a framework and compiler and just stick to that otherwise you're lost in the woods. And heaven forbid you take a long sabbatical, because when you return everything will have changed.
Re: Today’s JavaScript, from an outsider’s perspective (2020)
#8Module 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.
Re: Today’s JavaScript, from an outsider’s perspective (2020)
#9All he had to do was run `node index.mjs` or `npm run start` to have his index recognized as a module. Node DOES not read package.json, npm (node package manager) does. Node is not the package manager, so of course changes to package.json won't affect running `node index.js` However, node recognizes the file extension mjs as a module and will execute it as such. So renaming the extension of the script would work. Alt…
It only makes sense because you understand the decisions behind it. Try teaching JS to someone with little experience — they don’t care that the browser wants one kind of module and Node wants another. They don’t know what a module is, they just want their code to run
The article is making the whole thing sound arcane and unreasonable when the distinction between package managers and runtimes has been the case for decades.
Expecting package.json (a package manager file) to alter the behavior of node (the executable runtime) shows a lack of even first principle knowledge of computer languages, runtimes, or package managers.
I don't feel bad in the slightest, because math feels like shit too when you first get into it. But the reasons are mostly sound, so complaints are mostly just whining.
Re: Today’s JavaScript, from an outsider’s perspective (2020)
#10I can totally relate to this, even after working professionally with Angular for 3+ years and generally with JavaScript for way more than that.
I recently set up a quick JS project from scratch that needed a few different npm packages and ended up spending more time understanding the >three< different ways I had to use to import the different packages (because the returned errors were utterly useless), than actually writing the business logic...