Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
refactor(accounts-controller)!: revert wildcard export (#5300)
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> Using a wildcard export in the root `index.ts` of a package is, regrettably, not an ideal practice. This file is very useful because it gives us a way to understand everything that a package publicly exports at a glance. In using a wildcard export, however, we lose this visibility. Because all symbols marked with `export` will automatically become exports of the package, it is possible to introduce a new export without even knowing about it. We also lose the ability to export a symbol purely for internal purposes, which is useful for tests. As it relates to the change being reverted, because of the introduction of this wildcard export, new exports have been introduced which will now need to be reverted in a new major version, namely `AllowedActions` and `AllowedEvents`. This is non-ideal; we should not have to introduce major versions if we do not need to, because they are disruptive. Elsewhere it was noted that needing to add an export manually to this list is a small pain point especially if other subdirectories also use `index.ts`. I would argue that not knowing about exports (regardless of at which level exports occur) creates _more_ trouble in the long run. That is, the small pain point is a intentional feature and not a bug :) ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> See #5224. ## Changelog <!-- If you're making any consumer-facing changes, list those changes here as if you were updating a changelog, using the template below as a guide. (CATEGORY is one of BREAKING, ADDED, CHANGED, DEPRECATED, REMOVED, or FIXED. For security-related issues, follow the Security Advisory process.) Please take care to name the exact pieces of the API you've added or changed (e.g. types, interfaces, functions, or methods). If there are any breaking changes, make sure to offer a solution for consumers to follow once they upgrade to the changes. Finally, if you're only making changes to development scripts or tests, you may replace the template below with "None". --> (None; no functional changes) ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've highlighted breaking changes using the "BREAKING" category above as appropriate - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
- Loading branch information