Use multiple exports

[ibc]

Details

• Use exports field in package.json instead of main and types and module fields.
• Works in ES and CJS (CommonJS) environments.

Before

import * as rtpJs from 'rtp.js';

const { packets, utils } = rtpJs;

After

import * as packets from 'rtp.js/packets';
import * as utils from 'rtp.js/utils';

lib folder

lib
├── packets.cjs
├── packets.cjs.map
├── packets.d.ts
├── packets.mjs
├── packets.mjs.map
├── utils
│   ├── helpers.cjs
│   ├── helpers.cjs.map
│   ├── helpers.mjs
│   └── helpers.mjs.map
├── utils.cjs
├── utils.cjs.map
├── utils.d.ts
├── utils.mjs
└── utils.mjs.map

Do TS types work?

Yes, tested.

[satoren]

First, I will comment based on the assumption that the purpose of splitting is to reduce the bundle size.

I think it’s a matter of preference, but I believe having a main that exports everything would be a good idea. Since consumers usually use a bundler, when using ESM, tree shaking will still be performed even without excessive splitting. Additionally, adding "sideEffects": false to package.json is expected to further improve tree shaking efficiency.

People who care about size are definitely using a bundler.

[ibc]

I don't care about library size. This is intended to be a library for Node despite it works in browsers too. My goal is to provide a modern import mechanism instead of the classic index based single import which IMHO looks ancient.

With that in mind, I am not sure why I am doing bundling of packets and utils. Instead I would prefer to have 3 lib folders, lib-es, lib-cjs and types, and replicate in all those folders the whole file tree of src folder:

• lib-es/ would contain .mts files.
• lib-cjs/ would contain .cjs files.
• types/ would contain .d.ts files.
• I see no reason to have two types/ folder, one with .d.mts files and another with .d.ts files, because in my experiments, those files are exactly the same when generating them with rollup with rollup-dst-plugin using format "es" and "cjs".

Then the exports in package.json would be similar to what I have done in this PR, so entry points would also be "rtp.js/packets" and "rtp.js/utils".

In summary, despite what I have done in this PR so far, I see no reason to bundle anything.

Does it make sense?

[ibc]

Actually I'm doing exactly that with babel directly and getting rid of rollup. Working on it.

[satoren]

I see. I don’t think exporting individually is necessarily the modern approach.

Having multiple entry points for exports has specific advantages, and if none of these apply, there is no real benefit to splitting:

• In the case of CJS, tree shaking does not work properly, so splitting helps reduce bundle size (improving runtime load speed).
• For large libraries, splitting can improve load speed during development.
• When a library serves a wide range of purposes and has diverse use cases.

Additionally, even in a Node.js environment, keeping the size small can be beneficial, such as for AWS Lambda, etc.

[ibc]

Honestly I am not focusing on tree shaking or lib size. My points are:

• I don't want to only have CJS in the published library. It's 2025 already.
• Having only ESM in published library is a bit problematic yet due to some projects/frameworks/utils not supporting or enabling ESM yet.
• So I want to expose both ESM and CJS in the published library.
• And I also want to expose multiple entry points because we are in 2025 and we can do it better than exposing everything in a single index/dist/bundle main and unique export.
• But that doesn't mean that we need to bundle anything and that's why I am getting rid of rollup. It's up to applications and library consumers to decide whether they want to bundle their code (and deps) or not. A library should not make those assumptions.

[ibc]

@satoren I'm doing all that in this new PR #39.

[satoren]

If you care about size, I recommend adding the following action to your CI, as it can be quite useful.

https://github.com/andresz1/size-limit-action

[ibc]

NOTE: Replacing this PR with this new one: #39

[ibc]

I'm closing this PR in favour of #39 which does more things and keeps backwards compatibility for consumers expecting CommonJS modules with single entry point.