Indeed - right now I have to run microbundle multiple times in order to handle disparate input-output flows.

So I was thinking how this thing can be handled, I think there are 2 fundamental ways of providing this feature (I'll talk about them later)

At the moment there is a possibility to pass multiple entry points, even with a glob pattern and for each of the entry points microbundle creates several files (1 for each format) - they all land in the single, specified directory. I think that there is actually no need for this in its current form. I mean - there is a need for a single entry point configured with standard package.json fields (main, module) and there is a need for creating additional, alternative, entry points which need to get "proxy" directories with single package.json in them (example of such usage would be stockroom/inline).

Actually we could also support additional targets, but how to do that have to be figured out. What I mean by additional targets? React Native (react-native field in package.json) and better differentiating between node & browser builds (leveraging browser field in the root package.json). That is just another problem though, but I'll discuss it later - at the end of the post.

Also ideally we could run a single command of microbundle and have it all done in a single pass.

Configuration

At the moment when configuring multiple entries we can specify both input files and output directory, but it cannot quite work like that - when providing additional/alternative entries we need to reflect entry name in the package's directory structure. So actually we have 2 options for this:
a) output created files to the dist (output) directory, like normal, and create "proxy" directories somehow. But how? Their names have to be specified (we could come up with some convention based on the structure in the source directory) - if we provide a config option for this it seems that it will be quite complicated to use this feature, if we go with convention it could work
b) output created files to created "proxy" directories - again we have a problem of specifying input files/entries names pairs, but if we ignore output option entirely for those it seems reasonable to rely on convention and be done with it

Convention

We could support special name.entry.js convention and do all of the fancy stuff mentioned above based on it.

My choice would be...

A mix of configuration and convention approaches - I wouldn't ignore output option ever and create "proxy" directories based on the convention (structure of the source directory). That way all of the created files would be in a single directory (clarity) and we would have a nice way of specifying additional entries (opt-in when options gets used) with automatic creation of "proxy" directories.

Additional notes
Would be cool to warn people that they have to update their files in package.json (or that they cannot ignore those in .npmignore) with created directories.

Additional "main" entries - react-native, browser
As to react-native - metro bundler understands .native.js so it should be possible to provide "overrides" for each file with a sibling file with that extension (support for this can be easily added by providing extensions: ['.native.js', '.js'] to the rollup-plugin-node-resolve). Before bundling we can check if for the specified entry point there is an additional .native.js file and if there is we can create additional output bundle for it. We should also check for existance of react-native key in the root package.json - in such case we should create additional output bundle and add .native.js to possible extensions (in this case we wouldnt check if there is entry_name.native.js file, because we know that the package wants to have react-native alternative, as it specifies it in the package.json, but it might want to "override" only some modules and not the entry point itself). For react-native it's possible to output only a cjs format as it doesnt support anything else.

Similar thing could be done for browsers, but we would have to "invent" (?) .browser.js extension and automatically treat main as the entry point targeting node. About this I'm not yet sure how exactly it would work, and I need to wrap this up (wife looking at me dangerously 😉), so I'll leave this thought for now.

I think I'd prefer to have Microbundle generate directories with derived package.json files like Kent's solution. It would be difficult to infer when a file needs to be treated as an entry versus just a second bundle, we'll likely have to resort to using configuration for that (or the filename convention you mentioned, but I am wary of dynamically changing names - that breaks src / dist parity which makes Node a pain).

but I am wary of dynamically changing names - that breaks src / dist parity which makes Node a pain).

Could you elaborate on this? There is no parity at the moment (w are flat bundling) between src and dist.

I think convention files are more error-prone, so I'd suggest configuration is a better choice for this. Anyhow - I've started working on this slowly, hopefully I'll present a PR soon-ish, so we can discuss used approach then.

Ah but there is, just it's only for multiple entries: their names and locations are mirrored in dist and they are automatically treated as externals of eachother.

Would be great to add a test for this to see whats the expected result. By quickly inspecting unistore and stockroom dist files I cant see any correlation between built files, all seem to be completely different bundles without sharing deps between each other (except probably some externals from package.json)

OK, i think I've found example use of what you were talking about (which is microbundle itself 😄 ):

Ah but there is, just it's only for multiple entries: their names and locations are mirrored in dist and they are automatically treated as externals of eachother.

Need to look later how unistore/stockroom are different (maybe they just do not refer to each other? i suspect now that they do not refer to their "entries" directly, but probably just to some other imported internal modules and thats why other modules get duplicated - which also doesnt seem ok) or if Ive missed something when inspecting them.

I'm not sure yet, because I haven't experimented with this freshness in rollup yet, that ultimately we should use code-splitting (which is available already). This would simplify the microbundle's code, make those things more automatic and we could end up with no duplication between outputted files.

Seriously, i still can't understand for what you are talking about 😆

Rollup support multiple entry points anyway, even without the code splitting and etc, just pass array to input option, which array even can hold not only strings but inputOptions.

Regarding input:

String/ String[] The bundle's entry point (e.g. your main.js or app.js or index.js). If you enable experimentalCodeSplitting, you can provide an array of entry points which will be bundled to separate chunks.

I think what you mean is that multiple configuration can be passed to rollup in array form, i.e.

export default [cjsConfig, esConfig, umdConfig]

Those configs would be completely separate though and we'd ideally would like to end up with 0 repetition between output bundles.

Oh yea yea, I was sleepy 😪

Yup, finally got it. And recently i backed to the @rolldown, so i quickly implemented it in few lines, of course plus bonus features as it was dreamt.

Support rich config files, multiple entry points and basic placeholders.

Creates the following bundles

• ESM: dist/es-bundle-foo.mjs for the src/foo.js
• CJS: dist/foo.cjs.js for the src/foo.js
• ESM: dist/es-bundle-bar.mjs for the src/bar.js
• CJS: dist/bar.cjs.js for the src/bar.js
• CJS: dist/cli-cli.common.js for src/cli.js

Is this feature still being worked on? Keen to see it implemented!

I find it confusing that's cited as a feature in the README.md.
or am I missing something? should we remove that line?

Same @leonardodino Is there already a way to support multiple entry modules? Or is the README wrong?

If there is already a way to support multiple non-disparate entry modules, it should probably be documented otherwise it's just confusing to say it exists but not say how to use it

Same @leonardodino Is there already a way to support multiple entry modules? Or is the README wrong?

If there is already a way to support multiple non-disparate entry modules, it should probably be documented otherwise it's just confusing to say it exists but not say how to use it

I'm trying to do the same thing, I want to create a single package for a collection of React components but make it possible for users to access sub components without having to import everything else. Struggling to find a way to do this at the moment.

@gregrafferty No need for separate bundles. Just use named exports and all popular bundlers will take care of the rest via tree-shaking.

@gregrafferty No need for separate bundles. Just use named exports and all popular bundlers will take care of the rest via tree-shaking.

Ah that's great, thanks for the info. I've had a few problems with this in the past so sometimes I get a bit paranoid about it!