Distribute module entry

[Andarist]

This is a trial PR. Ideally I'd like to send similar PRs to all your callbag repositories.

Advantages?

• making it tree-shakeable when using reexporting packages (similar to callbag-basics, but i.e. we maintain our own package of callbags and import everything directly from it, instead of using direct imports)
• making scope hoisting aka module concatenation in webpack possible - webpack wraps each CJS lib with a runtime module closure, which costs around 17 bytes (each). Callbags aims to be super small, so I personally think that those 17 bytes are worth fighting for 😉
• CJS files being now in strict mode, supposedly giving some engine benefits in node.js (not 100% sure about this though). This could ofc be added manually, but now rollup ensures directive being added when building CJS file

[staltz]

I've been thinking a lot about this since this issue came up: staltz/callbag-basics#13 and I think CommonJS (require) is not the nicest solution for the future, I'm looking forward for https://github.com/ry/deno, but that said in the meanwhile it is also the simplest module type which works everywhere. I understand the advantages that you listed, but I think you could publish callbag-share-es as a fork of this project. Anyway I think that these small modules won't evolve a lot, since they are so focused on one thing. How about we do like that?

[Andarist]

CommonJS (require) is not the nicest solution for the future, [...], but that said in the meanwhile it is also the simplest module type which works everywhere.

This PR does not remove CommonJS file, it just aims to ship both ESM and CJS to npm. Node and older bundlers would just chose what's defined in package.json#main (cjs file) and modern bundlers, i.e. webpack would chose what's defined in package.json#module (esm file).

but I think you could publish callbag-share-es as a fork of this project. Anyway I think that these small modules won't evolve a lot, since they are so focused on one thing. How about we do like that?

That's ofc an option, but having to fork 17 modules (all of callbag-basics) and keeping them up to do is not something I'd personally like to do. I mean - costs outweighs the benefits for me in this situation, especially if a package can be configured (fairly easily looking on the changes introduced in this PR) in a way supporting both CJS & ESM worlds.

Also I care about discoverability, having separate CJS and ESM packages hurts that, confuses people and makes it harder to support isomorphic apps/libraries (assuming u'd like to have "the best" option used depending on the environment).

I understand if you don't like it for some reason, although from my point of view it's a low-cost change. Anyway - gonna respect any decision you take on that. Value of callbags to me is way greater than some extra bytes shipped to production 😉.

[staltz]

Where does $npm_package_module come from? Some new npm? rollup?

[Andarist]

https://docs.npmjs.com/misc/scripts#packagejson-vars

Not sure when it was added, but it it's available for quite some time. I can inline contents of those, but it nicely guards against accidental spelling mistakes and such.

[staltz]

Nice! Seems like it's supported since October 2017 or even before that, so should cover npm v5.

[staltz]

I've been thinking a lot about this, not just because of your PR, but also because of callbag/callbag#33 and staltz/callbag-basics#13 , and I think I'll merge this PR and ~5 other similar PRs, but not more than that. I understand and agree with your arguments related to callbags, ESM, CJS, and optimizations. So, PR will be merged. :)

---

Now here comes a very different topic. You can skip this unless you are curious about my other projects.

You were secretly part of an experiment I'm running to try different collaboration models for open source. The reason why I'm careful to merge this PR is not because I disagree with it (I actually agree with it), but because I'm trying to change the current mentality of forcing agreements as a way to progress open source projects.

Prior to GitHub being acquired by Microsoft, I was already thinking about how to reduce maintainer centralization, particularly with this blog post: https://staltz.com/open-source-without-maintainers.html . After the acquisition, some people who dislike Microsoft really wanted to build a peer-to-peer alternative to GitHub, and I'm included. We're building it: [1] and [2] and [3]. And it will also avoid/reduce maintainer centralization, because in a peer-to-peer system there are hardly any administrative powers, so we need to think about a collaboration model which is more commons-driven.

The problems I perceived with GitHub-style repos and/or centralized maintenance are:

• Maintainer is put on the throne: has more status, but also gets more requests
• Maintainer does a lot of different roles (writes code, does community management, reviews PRs, etc) and leads to burnout
• Forks of a project are de-emphasized compared to the original repo, don't share the status the main maintainer has
• PRs sometimes include a lot of begging and appeal
• PRs are accepted by clever argumentation to force the maintainer to agree with the request
• Such thing as "open source lobbying" is real, people are hiring for that skill
• Projects abandoned by the original author may be still actively maintained by other forks, but this is often unclear from GitHub, unless prior maintainer explicitly gives admin rights to the original repo

These are all problems that lead to cementing the concept of a centralized maintainer for the project, and now most of the open source projects expect there to be a BDFL-like role. As a consequence, even when the benevolent dictator doesn't want to be a dictator, the dictator can hardly escape and there still is a lot of pledging for agreements.

I took a different approach where I looked at "disagreement" and thought that it isn't a negative thing at all. Agreement is over-rated, but it also tends to lead to monolith projects. If you imagine a maintainer who very easily merges PRs of any kind, then the quality of the project deteriorates into a state where the library does everything for everyone, with no modularity or separation of concerns. Good design is about simplicity and removal of moving parts, but that's not the case for monolith projects.

I thought about the term "Supportive Disagreement" to describe how to preserve disagreement but enhance collaboration, and Callbag is one of the first experiments in supportive disagreement. The consensus surface is minimized: you only need to agree with the callbag spec. That's what we agree to agree on, the rest is all up to people to figure out. None of my callbag libraries are in this callbag organization, because I don't want to feel official. I am not official. I'm not a maintainer. This may sound unusual, but I'm not committed to maintaining callbags. I'm committed to supporting people find their own way.

My favorite case of 100% supportive disagreement was staltz/callbag-observe#1 where zebulonj wanted the library to be a bit different, and I disagreed, but supported him to make a fork, closed his PR, and then celebrated his fork on twitter, and there was no conflict at all.

The Wiki is also a great example of disagreement with collaboration. People make a library, and they update the Wiki. I may not like or agree with a package a person makes, but the point is I don't need to agree with them. They don't need my approval. They can just do it. This ends up optimizing the speed of progress in the community, as well as the feeling of being able to make an impact without the approval of a BDFL. Suddenly, anyone can shine in the community. Freedom to disagree, and specially, the lack of conflict and shame in disagreements, frees people to do what they feel is right. It is also quickly decentralizing the status and merit that is usually reserved to the BDFL. I'm very glad that some people made their first library ever, as a callbag utility.

Freedom to disagree creates space for divergence and creativity, but also convergence is important. Convergence is whenever we mix these diverging ideas and merge them together, literally with a merge commit. In typical centralized GitHub projects, divergence (e.g. forks) is a temporary thing you do so that you can quickly go back, through convergence/agreement. Should convergence always be up to an official maintainer?

Just as people have volunteered to create their own solutions, others can volunteer to merge solutions. Imagine there is staltz/callbag-share and Andarist/callbag-share with two separate conflicting features. Then some person comes along and volunteers to create someperson/callbag-share which merges those other two repos. Imagine if this forks chart would be the frontdoor of the community, so that all forks are put on an equal level.

It would also help attach responsibility to interest. Currently, the maintainer is responsible for all the code, and the requester is interested in a change, even if the change is presented as a PR, it's mostly just an interest, not a responsibility.

For instance, in this PR, you had the interest:

Ideally I'd like to send similar PRs...
I personally think that those 17 bytes are worth fighting for...
Also I care about discoverability...

But you tossed the responsibility back to me:

having to fork 17 modules (all of callbag-basics) and keeping them up to do is not something I'd personally like to do.

(I hope I don't sound like I'm blaming, I'm not!) And this is very common to happen in every project, but I believe we can attach responsibility to interest. For instance, so far no one has asked me to build a callbag operator for them. And I'm sure it could have been different, because I'm familiar with the RxJS project where it's very common for people to request the maintainers for a new operator they are interested in. In the Callbag community, everyone who had interest in an operator took the responsibility to do so. Imagine if this were true not only for creating new operators, but also for other cross-cutting concerns, including (not limited to) ESM packaging. Imagine, for instance, that instead of centralizing efforts on callbag-basics, we would also build callbag-toolkit, with slightly more operators, ESM support everywhere, etc.

In short: we're wasting too much time waiting for the maintainer to make up his mind. We're wasting too much potential by waiting for ideas to get approval. We're attributing merit unfairly to the maintainer who just clicked "merge" when it's often someone else who made the commit.

I'm aware this challenges the current maintainer-oriented work culture, but I want to do what I can to show that there are better ways. I'm not in a hurry, I think this will take a while so people can believe they are truly free to create without approval.

[Andarist]

Sorry for not answering sooner - crazy time in my life atm.

I can't say I wouldn't like some kind of other OSS collaboration mode - both from user & author perspective. Things & problems you mention are very much present in today's state of minds and I truly believe that people should change their attitude towards OSS work - participate more, open collaboration even more.

From front-end perspective convergence is IMHO really important though - we want our dependencies to be deduped if possible and I find it hard to believe that it's a scalable solution to fork-if-needed building blocks. This is not the same as forking direct dependencies - I quite often do that (still proposing changes to original authors, so ideally my changes can be merged upstream). It's way easier to maintain fork of libraries to use them in our apps than to fork libraries used by libraries we use or to fork behemoth tools like webpack, babel etc - for those it's 90% of the time more future-proof, time-saving to collaborate on a change or to find a workaround.

I also applaud "Supportive disagreement" approach, but there are times when it applies (API disputes, adding functionality etc) and there are times when it doesn't apply as much (such as tooling configuration).

I'd really like to see a community collaboration model in practice (without a central maintainer), but to make it work I would expect people's mindset changed (over time ofc) and some kind of tooling (probably just expanded options of current tooling like GitHub etc) that would aid all of this (smth like voting system, test coverage requirements etc). This would have to be (in my opinion) a system with "eventual convergence" though, as I believe we can help each other & develop faster only through a collaboration - and making it too distributed across forks would actually slow the overall progress too much (just personal doubt).