-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
[New] extensions
: allow enforcement decision overrides based on specifier
#3105
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3105 +/- ##
==========================================
+ Coverage 90.45% 95.16% +4.71%
==========================================
Files 84 84
Lines 3634 3643 +9
Branches 1279 1285 +6
==========================================
+ Hits 3287 3467 +180
+ Misses 347 176 -171 ☔ View full report in Codecov by Sentry. |
1c127b7
to
b067170
Compare
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.
What happens if two contradictory pathGroupOverrides options end up applying to the same file?
extensions
: allow enforcement decision overrides based on specifier
It mirrors the behavior of |
b067170
to
344df04
Compare
@ljharb Did this PR need any further work? |
@Xunnamius there's a few lines in the diff that aren't covered by tests. |
344df04
to
7a69297
Compare
This PR implements in
import/extensions
: a new option enabling developers to override the decision to enforce or ignore extensions for imports with matching specifiers.A demo package containing this feature is temporarily available for easy testing:
Prevent false negatives when checking the extensions of bespoke imports
I already use
import/order
with custompathGroups
. This allows me to control the grouping of certain paths, such as custom aliases fromtsconfig.json
'spaths
. This in turn ensures all imports are sorted properly, even when the project is using syntactically sound but otherwise bespoke custom aliases likemy-project:api.js
(in lieu of../../../../src/api.js
).Unfortunately, if I mistype
my-project:api
(i.e. I forgot the extension), theimport/extensions
rule will still pass; the enforcement decision is "ignore" when it should have been "enforce". This is because, likeimport/order
, the grouping strategy employed by this rule is quite coarse-grained, but unlikeimport/order
, this rule is missing apathGroups
-like setting for finer-grained sorting. The goal of this PR is to fill that gap.The documentation updates associated with the changes in this PR are part of a separate PR and can be previewed here (towards the bottom of the section). This PR also includes tests.