-
Notifications
You must be signed in to change notification settings - Fork 5
fix: Fix entity exports for ESM projects #298
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
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #298 +/- ##
=======================================
Coverage 97.39% 97.39%
=======================================
Files 87 87
Lines 11889 11894 +5
Branches 1017 1017
=======================================
+ Hits 11579 11584 +5
Misses 303 303
Partials 7 7
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
faa8d9a to
4c6e056
Compare
4c6e056 to
02b9c1b
Compare
wschurman
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely cool with this new pattern! Is there a lint rule we can apply to disallow default exports going forward? I think this would be too easy to for contributors to accidentally break it without a lint rule since most people are accustomed to adding default exports.
packages/entity-example/src/entities/AllowIfUserOwnerPrivacyRule.ts
Outdated
Show resolved
Hide resolved
02b9c1b to
8d00054
Compare
c7515f0 to
a0521b8
Compare
986240b to
9d6692e
Compare
a0521b8 to
692d8c4
Compare
692d8c4 to
86c33eb
Compare
5597581 to
847981b
Compare
86c33eb to
7eb50b5
Compare
9270ae3 to
4bdeee5
Compare
0351888 to
74553d8
Compare
aa954cb to
0bf670c
Compare
f00539d to
cd9cf6c
Compare
cd9cf6c to
c2ca1e9
Compare
c2ca1e9 to
398852e
Compare
Merge activity
|
Before this commit, for projects with `"type": "module"`, anything exported from a file `export default` was not resolvable from the barrel file as a named export. After this change, the interface of the index is unchanged, but ESM projects can use it. To test this, the entity-example package is given `"type": "module"`, and changed to run with `node --experimental-transform-types`. Its imports from other packages do not need to change. The other integration tests passing are evidence that commonjs modules also do not need to change their imports. This commit also adds an eslint rule to enforce this standard.

Why
I noticed that a project with
"type": "module"set cannot import anything from@expo/entity's index which uses theexport { default as <name> }pattern.How
I changed the example project to reveal the bug when run, replaced
export defaultwithexportin all non-test entity files, and regenerated the barrel file.Test Plan
To see the problem, revert the changes only in
packages/entityand runyarn startinpackages/entity-example. But notice that no package which hasimport { foo } from '@expo/entity';needs to change them.