it seems so insane that there are competing module patterns in a single language, but perhaps i'm ignorant. are there other languages with such incompatibilities on a fundamental component?
Node Modules at War: Why CommonJS and ES Modules Can’t Get Along
91–100 of 152 posts
Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along
#92Honestly, all I need is a standardized way to publish and consume packages directly as Typescript (right now you can point "main" & "types to it, but I'd rather something like export maps) because the transpilation should be done by the end user as you can't assume which build target they might prefer.
Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along
#93This is an important issue to consider because as we are witnesses a Cambrian Explosion in 'new tech' (and by the way, in 'new' we can include evolutions of 'current') ... we need to grasp that 'a new piece' is is just going to be 'one of many pieces'.
My first instinct these days is how that funky new bit of Lego fits with all the other bits of Lego.
When you start there, it's becomes easy to understand just how incumbent C++ and javascript are, even with all their necessary spells and arcane witchcraft.
Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along
#94Wow, I've been coding JS/Typescript frontends for years and somehow completely missed out knowing anything about CJS & ESM or their differences. I guess it's all irrelevant when you don't use Node, aren't publishing libraries, and are compiling all JavaScript into bundles for deployment and never read the bundled code.
Unless you are developing libraries which will be published to the nodejs ecosystem, you really don't need to worry about this.
You pick one of these when you first create your app which is typically based on whatever framework or template you are starting from, and you just always stick with that.
Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along
#95JavaScript just gives to much options. I keep having problems with libraries because ES6 allows import x from "library"; import {x} from "library"; import * as x from "library"; import {x as y} from "library"; Just to compare Java uses this: import java.lang.Double; import java.lang.*; No renaming, not a gazillion options during in- and export, but one statement. If you want to rename something, assign it to a variab…
So what happens when you need to deal with java.time and Joda Time in the same class (e.g. because Joda was part of your public API but you're migrating to Java time). Fully qualified names everywhere, when it would be nicer to have a construct like: import org.joda.time.Instant as JodaInstant; The rest of the weirdness is to make it look like JS destructuring
Version the API and switch to Java-time everywhere. Or forward everything to another class.
Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along
#96Meanwhile, I found this on how Deno handles modules (it's all esm): https://www.sitepoint.com/deno-module-system-a-beginners-gui... Note that - if you can get an esm out of your cjs - and it doesn't use any nodejs apis unsupported by deno, then you might be able to use it: > (...) Several CDNs can convert npm/CommonJS packages to ES2015 module URLs, including: Skypack.dev, jspm.org, unpkg.com (add a ?module querystri…
> (it's all esm)
Always has been.
Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along
#97I use the ESM dependency to load ESM modules as a CJS shim:
https://www.npmjs.com/package/esm
I highly recommend it. Really let’s you unify on ESM modules without much thought
Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along
#98Earlier quoted context omitted.
So what happens when you need to deal with java.time and Joda Time in the same class (e.g. because Joda was part of your public API but you're migrating to Java time). Fully qualified names everywhere, when it would be nicer to have a construct like: import org.joda.time.Instant as JodaInstant; The rest of the weirdness is to make it look like JS destructuring
Version the API and switch to Java-time everywhere. Or forward everything to another class.
Unless you're going to duplicate the logic too, you're still going to have the facade class providing the legacy Joda API that also needs to use the new types to forward onto the new API.
That class doing that transformation will need to refer to both the Joda and java.time class.
Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along
#99Earlier quoted context omitted.
> should instead have a CJS shim OP wrote, note that it’s easy to write an ESM wrapper for CJS libraries, but it’s not possible to write a CJS wrapper for ESM libraries.
It's not possible to write a nice automated transparent one for arbitrary libraries because of top level await, but it's totally possible for the 95%.
Re your point OP also commented/quoted someone with “I don’t think designing a system with the blanket assumption that some feature just won’t get used is a viable path.”
Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along
#100I’ll conclude with three guidelines for library authors to follow: Provide a CJS version of your library Provide a thin ESM wrapper for your CJS Add an exports map to your package.json This seems like the same fallacy of python’s 2to3, and why they should have written 3to2 instead. If ESM is the new way, library authors should instead have a CJS shim to prevent fossilization of cruft.
> should instead have a CJS shim OP wrote, note that it’s easy to write an ESM wrapper for CJS libraries, but it’s not possible to write a CJS wrapper for ESM libraries.
I'm pretty sure services like pika.dev/skypack.dev/jspm.io are trying to solve the CJS to ESM problem so you can use it directly in the browser (or deno).
Last time I checked they seemed to lean into using rollup to take care of the translation under the covers.