-
Notifications
You must be signed in to change notification settings - Fork 153
Feature request: provide sub-path export for envelopes #3597
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
While working on this, we should also export |
Should we also change the |
I think that's risky and we'd be better off doing it in the next major version. We already provide sub-path exports for schemas, so even if they're hand-coded, they're there and people might be relying on them. The envelopes ones are additive, so we can do it now. |
This issue is now closed. Please be mindful that future comments are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so. |
This is now released under v2.15.0 version! |
Use case
As a customer, I'd like to use Parser envelopes without having to import all of them at once, thus keeping my bundle size in check.
Right now if I use any one of the envelopes, they are all imported and included in my bundle since they're exposed only as a barrel export.
Basically I'd like to go from this:
to this:
similar to what we're already doing for schemas.
Solution/User Experience
Since we're exporting a large number of modules that are under the same directory, I'd like to try using a more generic and scalable solution than the one I introduced a while back.
Instead of creating one entry for each item in the
package.json#exports
field, we could instead use*
similar to this example.The tradeoff here is that we'll need to be careful with what we put in the envelopes directory, but in this specific instance I think it's safe to do it since we're likely not going to add anything different there.
To keep names aligned with the exports we provided for schemas, we might have to rename some files.
Alternative solutions
Acknowledgment
Future readers
Please react with 👍 and your use case to help us understand customer demand.
The text was updated successfully, but these errors were encountered: