-
Notifications
You must be signed in to change notification settings - Fork 62
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
Imports conditions #551
Imports conditions #551
Conversation
🦋 Changeset detectedLatest commit: 497bf6a The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #551 +/- ##
==========================================
+ Coverage 91.79% 91.80% +0.01%
==========================================
Files 38 41 +3
Lines 1730 2002 +272
Branches 493 585 +92
==========================================
+ Hits 1588 1838 +250
- Misses 133 154 +21
- Partials 9 10 +1
☔ View full report in Codecov by Sentry. |
a163550
to
483cd76
Compare
This implements the design from #542 (comment) under an experimental flag
importsConditions
. There's still some stuff I probably want to change here (hence why it's under an experimental flag) but I'd like to try it out and see how it is to use first.A thing I didn't mention in the PR comment linked above that I've done here is for
imports
fields like this:We'll only generate two bundles for each format rather than three since the worker and default conditions resolve to the same place. (we use the shortest combination of conditions to name bundles)
Also, in the generated
.d.ts
files, we re-write imports from#something
to the resolved thing with the default condition applied. This is so that the.d.ts
files work inmoduleResolution: node
(though of course, when authoring packages, you need to use bundler or nodenext so that#something
can be resolved).In the future, I'm thinking of having essentially two
.d.ts
outputs, one with#something
replaced and one where it's not replaced, this would allow having different types for different conditions. I don't think that by itself would be that useful tbh since I'm guessing that most package consumers will not be configuringcustomConditions
in TS. Though what would be quite useful is thetypes@semver-range-of-ts-version
magical condition thing, specifically, we could essentially polyfill it formoduleResolution: node
viatypesVersions
without users having to deal withtypesVersions
. One slight problem with this is that withoutisolatedDeclarations
, you could accidentally rely on type information from a particular implementation of#something
and therefore generate the wrong.d.ts
files so I'm thinking if/when we implement this part, it'll probably stay experimental untilisolatedDeclarations
exists. (we could of course also just generate.d.ts
files for each set of conditions but that would be unacceptably slow imo)Also, one random thing that's interesting with this design (though I don't think I'd say it's really a problem) is that you can conditionally have different exports for different conditions except that you couldn't conditionally have a default export. (the implementations of a default export could be different for different conditions but you couldn't have a default export under some conditions and not under others)
cc @Andarist
Closes #542