mitt

Problem (#210) has no side effects on import, but does not declare . This prevents bundlers (webpack, Rollup, esbuild, Vite) from safely tree-shaking unused exports. Fix Add to . This is the standard field recommended by webpack and other bundlers for libraries that are pure (no global side effects when imported).

Co-authored-by: Jason Miller What is the purpose of this pull request? (put an "X" next to an item) [ ] Documentation update [ ] Bug fix [x] Feature [ ] Code style update (formatting) [ ] Refactoring (no functional changes) [ ] CI related changes [ ] Other, please explain: What changes did you make? (Give an overview) The function now returns a deregistration function that a consumer may call instead of . This pattern is present in other event emitter libraries, and it has a particular benefit that I care about. It allows consumers to avoid creating a variable to store the handler function. In other words, the handler function can be inlined into the arguments. (in the current API, it is possible to inline the handler function, but then it is impossible to ever deregister it). Allowing inlining via a deregistration function is a key API feature in my experience. I have seen bad things happen in enterprise codebases that were caused by developers creating handler function variables, which then degrade over time. Once the variable exists, future developers may decide to use it for other purposes. This is a classic maintenance risk where code loses its purpose and gets corrupted by multiple concerns. Inlining would prevent that. If the variable never exists in the first place, then the code would be more resilient to degradation over time. That's the idea at least. Is there anything you'd like reviewers to focus on? The deregistration function is a good pattern, but it involves creating a new object (arrow function) on each invocation of . I'm not well versed in JS engines but creating an object has implications for performance and GC. In typical usage I don't think this is an issue, by hypothetically there may be high performance consumers who call in high performance code loops, where allocating an object would degrade performance. If the creation of the object is not acceptable for this library, then we may consider implementing two different functions: one returning a deregistration function and one without (i.e. the current form). However, this would increase the library size a little. If neither of these are valid for the design decisions of this library, then please feel free to close this PR. Does this PR introduce a breaking change? (What changes might other developers need to make in their application due to this PR?) Yes. The function now returns a function instead of . All consumers who relied upon the function returning must update their code to ignore the return value.

What is the purpose of this pull request? (put an "X" next to an item) [ ] Documentation update [ ] Bug fix [ ] Feature [ ] Code style update (formatting) [ ] Refactoring (no functional changes) [ ] CI related changes [X] Other, please explain: Added to . Apparently, this can enable more tree-shaking, in some cases: documentation Other popular libraries, such as axios, have been adding this flag: https://github.com/axios/axios/pull/5025 What changes did you make? (Give an overview) See above Is there anything you'd like reviewers to focus on? It'd probably be smart for someone with a project that is directly using to test this change. Does this PR introduce a breaking change? (What changes might other developers need to make in their application due to this PR?) Shouldn't be a breaking change