3 ms·
ES modules have a problem: do they import the source code or the "binary" (minified code). As long as you're writing demos where the source code is the executab
by skybrian 3y ago
ES modules have a problem: do they import the source code or the "binary" (minified code). As long as you're writing demos where the source code is the executable, it's fine. This is great for browser demos.
But when you start using Typescript or npm modules that export minified code, or there's a CDN involved, finding the original source for a function gets increasingly difficult, the type definitions are in a different file, and breakpoints don't work. It's almost like debugging a binary.
Compiled languages like Go do a better job of making sure you can actually read the source code, because imports always import source code.
- spankalee 3y agoI don't understand the problem here, or why it's JS module specific. Source maps with pretty great, and if you're in a development setup where you say only compile out types and resolve import specifiers, they work spectacularly well, including in debuggers.
- skybrian 3y agoSource maps are indeed very helpful when they work, but in my experience, often they don’t for third-party modules. This seems to be an ecosystem thing. The documentation for package.json doesn’t mention sourcemaps? According to this bug [1], even the typescript compiler’s npm doesn’t include source or sourcemaps. [1] https://github.com/microsoft/TypeScript/issues/32207 https://github.com/microsoft/TypeScript/issues/32207
- brainbag 3y agoYeah, other than a project that was still on webpack, I can't think of any time in the last few years where this was a problem. Vite has made JavaScript apps nearly effortless for years now.