5 ms·
> It gets even more fun when you realize that module resolution isn't even specified, meaning that as far as a bundler is concerned, something like `import 'lod
by pbowyer 6y ago
> It gets even more fun when you realize that module resolution isn't even specified, meaning that as far as a bundler is concerned, something like `import 'lodash'` means completely different things for a browser vs a project installed via npm vs one installed via yarn v2...
Ugh, why does it have to be different between npm and yarn v2?
I'm an occasional JavaScripter and yetserday wrote an automation with Puppeteer.
The first line I wrote was
import puppeteer from 'puppeteer'
only for Node to fail on that. I thought that syntaxt was supported, but I had to change it to
const puppeteer = require('puppeteer');
I've no idea if it's a problem with my Node version (12) or what, but it was a real "Huh?" moment.
- acemarke 6y agoFWIW, that's not an `npm` vs `yarn` thing. That's a "Node has only recently added support for ES module syntax and it's still mostly experimental" thing: - https://nodejs.org/api/esm.html https://nodejs.org/api/esm.html - https://nodejs.medium.com/node-js-version-14-available-now-8170d384567e https://nodejs.medium.com/node-js-version-14-available-now-8...
- josephg 6y agoIts supported pretty well now but you need to explicitly switch ES module support on in nodejs. The easiest way is via the "type": "module" flag in the package.json file for your project.
- jdlshore 6y agoModules weren't production-grade until Node version 14. Before that, it used CommonJS modules ("require" instead of "import"). It's because Node was invented before EcmaScript modules existed. CommonJS worked well and supporting both was awkward, so the transition took a while.
- pwdisswordfish6 6y agoIt's an odd thing. The way people talk, you'd think NodeJS and JavaScript are synonymous. Turns out, NodeJS is this generation's JScript, including shoddy support for the language proper, and it includes vendor-specific extensions that you're expected to use instead. It has somehow though managed to escape any of the criticism that gets thrown at other projects pilloried for stuff like this.
- jiofih 6y agoNode came out way before any of these features were invented, and the ES committee knowingly broke compatibility when designing for the browser. Modules are supported since v14 but you have to opt in.
- pwdisswordfish6 6y agoThey didn't break compatibility. NodeJS never attempted to be compatible with the Web. The design work that TC-39 and the browser makers did is also much better than what the NodeJS community puts out. And it's a design that was in ECMAScript 6. Six years later, and you still have to opt in. The TypeScript team got it right, working in a way that NodeJS should have been taken lessons from.
- Scarbutt 6y agoThe design work that TC-39 and the browser makers did is also much better than what the NodeJS community puts out Like the dumb broken Maps and Sets?
- jiofih 6y agoYeah, technically better, at the cost of huge complexity. CommonJS was easy to implement anywhere and dead simple. We only need static analyzers and tree-shaking optimizations because the JS ecosystem went wild on dependencies. I honestly think we were better off 10 years ago. > NodeJS never attempted to be compatible with the Web It goes the other way around? Node caved in and support modules now, what has been done in tc-39 for web modules to be compatible with node (considering it predates all of it)? There is no “JS community vs Node community” btw.
- lucideer 6y ago> Ugh, why does it have to be different between npm and yarn v2? Mainly just because yarn v2 went off book[0]. npm vs yarn v1 is a more sane wold. [0] A perspective on Yarn v2 from the creator of Yarn v1: https://twitter.com/sebmck/status/1300664946645069830 https://twitter.com/sebmck/status/1300664946645069830