Dual publishing doesn't work

[zenparsing]

Serving different codebases to different consumers creates identity discontinuity problems.

For example, imagine that I have a popular library "foobar" and I want to migrate to ESM. My library will return certain object types to the consumer that are later accepted as inputs. In my library I branch based on whether a particular object "is an instance" of one of these types.

My library is used by two different consumers, A and B. A uses require. B uses import. According to the current version of this proposal, A will get the CJS version of the library (via "esm") and B will get the ESM version.

Let's say that A gets an object from "foo" and then passes it to B. B then passes it back to "foo". The ESM version of "foo" will determine that it is not an instance of the "foo" type, since it came from the CJS version of "foo".

The solution to this problem must involve always serving the same version (ESM or CJS) to all consumers.

Related: graphql/graphql-js#1479

[zenparsing]

As far as I can tell, there are only two ways to solve this problem.

First, let's assume that I'm dual-publishing in order to support older versions of NodeJS. Let's also assume that I want to avoid identity discontinuities by always serving the same source code for any particular version of NodeJS. In order to support both require and import my options are:

1. Always serve the CJS version (using import.meta.require to jump from ESM to CJS)
2. Always serve the ESM version (using some other technique to jump from CJS to ESM)

With the first approach, I might as well just not bother publishing ESM source. This doesn't appear to be much better than the current situation.

With the second approach, we'll need a new ability to jump from CJS to ESM, synchronously.

[zenparsing]

Another issue with dual publishing involves slight differences in semantics when switching from transpiled code to non-transpiled code. Usually a test suite will only test the transpiled code.

For instance, consider a library that publishes a class. Even though the Babel transform is designed to emulate the fact that class constructors can't be called without new, transpiled subclasses will still attempt to call the constructor as part of its super-call transform.

[MylesBorins]

Found this while doing research, hope you are doing well :D