tsdown is not stable enough to be used in a security- and safety-critical project.

@verytactical, I understand your concern, and I will not defend this decision (I used it as the simplest option here to get a result). What do you think about bundling using Rollup with rollup-plugin-dts?

I thought about sticking to plain old tsc, and running it twice.

Do we really need anything that advanced?

I would prefer to use bare tsc myself, but at the build stage, renaming files to .mjs for ESM is mandatory.
You could use the rewriteRelativeImportExtensions option from TypeScript 5.7, but then all imports must include the .ts extension:

import { BitString } from './boc/BitString.ts';

In other words, if building for CommonJS and ESM were possible using bare tsc, projects such as tsup, rolldown, and rollup-plugin-dts would never have been created.

I should also mention that there is another way to use .js files for both CommonJS and ESM in a bundle. This is "Subpath exports with multiple package.json". It's a bit old-fashioned, but it's still well supported by bundlers and native to Node.js. I will prepare the changes later and show what happens. The setup will be more complicated, but it will be possible to leave only tsc.

Sorry, I forgot to put meeting notes from the call with @radist2s.

The main problem here is that this change is inherently backwards incompatible: users would have to configure their build tools to select the exact desired build of the package and its transitive dependencies. It's very likely someone will just update the library, and get into a tarpit of debugging their build.

Worse, we create two separate versions of the library, albeit in the same version of the same npm package. This means that even if there is a single version of the @ton/core in a dependency tree, we might load both ESM and CJS versions at the same time, and suffer from instanceof problems.

So, even if we're ready to ignore this kind of DX problems that ensue from ESM/CJS hybrid libraries, we'd still have to release a new major version. And that version is 1, which means we're publicly promising to keep backward compatibility on all the interfaces, and pretty much all of them are really not good at the moment.

According to semver we can break stuff in minor versions prior to 1.0.0

Probably we should ditch all the instanceof checks and replace it with Symbol.for tags. I've seen the approach to fix the same problem from @preact/signals guys

According to semver we can break stuff in minor versions prior to 1.0.0

Probably we should ditch all the instanceof checks and replace it with Symbol.for tags. I've seen the approach to fix the same problem from @preact/signals guys

Well, I wish it was our instanceof, not in dependents. That'd make it much easier :)

@verytactical, unfortunately, I have not yet completed the compatibility study we agreed upon. I was urgently transferred to another project and asked not to be distracted until its release. I will return to this issue any day now.

Why these files have to be in sideEffects?

Neither Cell nor Bitstring should have any global state in them.

If we strictly follow the rules, then the structures of the form

static readonly EMPTY = new BitString(Buffer.alloc(0), 0, 0);

are side effects. But for the cases mentioned, I must agree that there will be no side effects. I will delete it if it raises questions, and change sideEffects to false.

This declaration is actually side effect free. It just creates dependency chain from the other file, but the file itself can be totally removed to optimize bundle size