Addendum

Author: andrewbranch

content/posts/2023-11-14_Is_NodeNext_Right_For_Libraries_That_Dont_Target_NodeJS.md

@@ -106,7 +106,9 @@ These are both **absolutely possible** via conditional package.json `"exports"`.
 
 This would direct bundlers to one module and Node.js to another, each having a completely different API. In this case, it would be impossible to write a single import declaration that works in both contexts, and TypeScript could be used to catch an error like this by type checking the input code under multiple `module`/`moduleResolution`/`customConditions` settings. But this is terrible, terrible practice! I don’t think I’ve ever seen this in a real npm package (and I have looked at a _lot_ of package.jsons in the last year).
 
-Indeed, the _only_ difference between `moduleResolution: bundler` and the CommonJS `moduleResolution: nodenext` algorithm in TypeScript is import conditions, and every resolution that can be made in the ESM `moduleResolution: nodenext` algorithm will be made the same way in `moduleResolution: bundler`, with the exception of where import conditions cause them to diverge. If there are other differences in the _real_ resolution algorithms of bundlers and Node.js, they are not reflected in TypeScript’s algorithm, so additional checking with TypeScript won’t help. In other words, module resolution is not an issue unless a package is doing something extra terrible with `"exports"`.
+Indeed, the _only_ difference between `moduleResolution: bundler` and the CommonJS `moduleResolution: nodenext` algorithm in TypeScript is import conditions, and every resolution that can be made in the ESM `moduleResolution: nodenext` algorithm will be made the same way in `moduleResolution: bundler`, with the exception of where import conditions cause them to diverge. (If there are other differences in the _real_ resolution algorithms of bundlers and Node.js, they are not reflected in TypeScript’s algorithm, so additional checking with TypeScript won’t help.) Keep in mind that bundlers came about in large part so that modules on npm, written under the assumption that only Node.js would be able to use them, could be used in the browser, which lacked a module system at the time. Bundlers would not be doing their job if their module resolution algorithms choked on Node.js code. Conditional exports _can_ be used to redirect a bundler, but doing this in a way that breaks the contract of the module that Node.js would see is arguably a bug.
+
+In other words, module resolution is not an issue unless a package is doing something extra terrible with `"exports"`.
 
 ## Module interop