3 ms·

All 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 manag

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

MaxLeiter 4y ago
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
- goldenkey 4y ago
  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.
  - chii 4y ago
    > shows a lack of even first principle knowledge of computer languages, runtimes, or package managers. it's more that the author has the expectation that a computer scientist (well versed in computer science) should be able to immediately discern the intricacies of software construction and engineering. The complexities of a software system is distinct and different from that of computer science. It's like saying that a physicist would be able to do the job of a construction civil engineer, because they know the physical theories of forces.
- chii 4y ago
  > Try teaching JS to someone with little experience which is why js is not a good language to start teaching someone without experience in another language (including the ecosystem). To learn js, it is necessary to learn about the module system that evolved from the browser (and the hacks made in the past, prior to having a module system). Then you must learn that node.js and npm, and optionally, webpack and/or other packing tools. It's very convoluted, and unnecessarily complex. However, this complexity isn't entirely one entity's fault. I think you'd find similar complexity in java, in the early years, around the dependency management ecosystem, before the advent of maven 2. Of course, you can just skip all of that, and go with the old C/C++ model, which is just copy/paste the code into a file in your project. For someone looking to test out some code they randomly found, this is probably the most recommended route imho.
  - deleted 4y ago
    [deleted]
- goldenkey 4y ago
  Sure, but at the same time, they shouldn't expect to just jump over an understanding of what the command `node` is versus `npm.` Previous experience or just a basic understanding of what the commands read, touch, and do, would have avoided most of their confusion.
- deleted 4y ago
  [deleted]
throw_m239339 4y ago
> 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.
- goldenkey 4y ago
  The module stuff is a different story and that's its own rabbit hole. I don't think its the crux of the blog post or even my comment. The purported issue was that changing the package.json type to module didn't fix things. That expectation is beyond amateur and I don't think there's really anything to complain about if one expects to bootstrap into a new programming language with package management, without understanding the general paradigm.
  - MaxLeiter 4y ago
    Well, they expected it because it's what node told them to do. from the article: John runs node index.js Node: Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
padolsey 4y ago
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.
- goldenkey 4y ago
  I have been across the block, from x86 asm to front-end and back-end JS stacks 20 miles high with preprocessors and dependencies. I haven't ever always done JS. I've dabbled in everything, so that hiatus you talk of, I've taken it many times over. I know the hell well that you speak of when learning some new vertically stacked artifact like the JS ecosystem. But I have no sympathy here because of the fundamental lack of cursory research or attempts done to grok what the node command does, versus the npm command. Jumping right in is a fine method but it doesn't call for complaints or a blog post. One should have an implicit understanding that jumping in without preparing, means a lot of stupid mistakes are going to be had. Get used to going from first principles would be my advice. Elon Musk did a lot by following that maxim. The same technique cuts through all the ecosystem bullshit when you stop letting the confounding and confusion depress and unravel oneself. "Perhaps I could best describe my experience of doing mathematics in terms of entering a dark mansion. You go into the first room and it's dark, completely dark. You stumble around, bumping into the furniture. Gradually, you learn where each piece of furniture is. And finally, after six months or so, you find the light switch and turn it on. Suddenly, it's all illuminated and you can see exactly where you were. Then you enter the next dark room..." Andrew John Wiles Dealing with these ecosystems is very similar to that. But all the dark rooms are similar to each other in spirit of shadows and highlights - so the more dark rooms one acclimates to, the less the future ones cause complaining, stress, or vitriol.
henbruas 4y ago
The documentation seems VERY clear that the "type" field in package.json DOES affect the node runtime: https://nodejs.org/api/packages.html#type https://nodejs.org/api/packages.html#type
tomashubelbauer 4y ago
> Node DOES not read package.json It does when you use ESM, it checks whether there's "type": "module" in package.json.

MaxLeiter 4y ago

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

goldenkey 4y ago
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.
- chii 4y ago
  > shows a lack of even first principle knowledge of computer languages, runtimes, or package managers. it's more that the author has the expectation that a computer scientist (well versed in computer science) should be able to immediately discern the intricacies of software construction and engineering. The complexities of a software system is distinct and different from that of computer science. It's like saying that a physicist would be able to do the job of a construction civil engineer, because they know the physical theories of forces.
chii 4y ago
> Try teaching JS to someone with little experience which is why js is not a good language to start teaching someone without experience in another language (including the ecosystem). To learn js, it is necessary to learn about the module system that evolved from the browser (and the hacks made in the past, prior to having a module system). Then you must learn that node.js and npm, and optionally, webpack and/or other packing tools. It's very convoluted, and unnecessarily complex. However, this complexity isn't entirely one entity's fault. I think you'd find similar complexity in java, in the early years, around the dependency management ecosystem, before the advent of maven 2. Of course, you can just skip all of that, and go with the old C/C++ model, which is just copy/paste the code into a file in your project. For someone looking to test out some code they randomly found, this is probably the most recommended route imho.
- deleted 4y ago
  [deleted]
goldenkey 4y ago
Sure, but at the same time, they shouldn't expect to just jump over an understanding of what the command `node` is versus `npm.` Previous experience or just a basic understanding of what the commands read, touch, and do, would have avoided most of their confusion.
deleted 4y ago
[deleted]

throw_m239339 4y ago

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

goldenkey 4y ago
The module stuff is a different story and that's its own rabbit hole. I don't think its the crux of the blog post or even my comment. The purported issue was that changing the package.json type to module didn't fix things. That expectation is beyond amateur and I don't think there's really anything to complain about if one expects to bootstrap into a new programming language with package management, without understanding the general paradigm.
- MaxLeiter 4y ago
  Well, they expected it because it's what node told them to do. from the article: John runs node index.js Node: Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.

padolsey 4y ago

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.

goldenkey 4y ago
I have been across the block, from x86 asm to front-end and back-end JS stacks 20 miles high with preprocessors and dependencies. I haven't ever always done JS. I've dabbled in everything, so that hiatus you talk of, I've taken it many times over. I know the hell well that you speak of when learning some new vertically stacked artifact like the JS ecosystem. But I have no sympathy here because of the fundamental lack of cursory research or attempts done to grok what the node command does, versus the npm command. Jumping right in is a fine method but it doesn't call for complaints or a blog post. One should have an implicit understanding that jumping in without preparing, means a lot of stupid mistakes are going to be had. Get used to going from first principles would be my advice. Elon Musk did a lot by following that maxim. The same technique cuts through all the ecosystem bullshit when you stop letting the confounding and confusion depress and unravel oneself. "Perhaps I could best describe my experience of doing mathematics in terms of entering a dark mansion. You go into the first room and it's dark, completely dark. You stumble around, bumping into the furniture. Gradually, you learn where each piece of furniture is. And finally, after six months or so, you find the light switch and turn it on. Suddenly, it's all illuminated and you can see exactly where you were. Then you enter the next dark room..." Andrew John Wiles Dealing with these ecosystems is very similar to that. But all the dark rooms are similar to each other in spirit of shadows and highlights - so the more dark rooms one acclimates to, the less the future ones cause complaining, stress, or vitriol.

henbruas 4y ago

The documentation seems VERY clear that the "type" field in package.json DOES affect the node runtime: https://nodejs.org/api/packages.html#type https://nodejs.org/api/packages.html#type

tomashubelbauer 4y ago

> Node DOES not read package.json It does when you use ESM, it checks whether there's "type": "module" in package.json.