Skip to content
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

[Fix] extensions: ignore type-only imports #2270

Merged
merged 1 commit into from
Oct 24, 2021
Merged

Conversation

jablko
Copy link
Contributor

@jablko jablko commented Oct 23, 2021

  1. Resolving type-only imports is only supported by eslint-import-resolver-typescript
  2. import/extensions rule currently errors on unresolved imports (I gather)

∴ disable import/extensions for type-only imports, along the lines of #2220.

Relates to #2267

@codecov
Copy link

codecov bot commented Oct 23, 2021

Codecov Report

Merging #2270 (ebfff94) into main (c3633c6) will decrease coverage by 0.03%.
The diff coverage is 100.00%.

❗ Current head ebfff94 differs from pull request most recent head 46c4709. Consider uploading reports for the commit 46c4709 to get more accurate results
Impacted file tree graph

@@            Coverage Diff             @@
##             main    #2270      +/-   ##
==========================================
- Coverage   94.63%   94.60%   -0.04%     
==========================================
  Files          65       65              
  Lines        2686     2688       +2     
  Branches      888      888              
==========================================
+ Hits         2542     2543       +1     
- Misses        144      145       +1     
Impacted Files Coverage Δ
src/rules/extensions.js 98.00% <100.00%> (-2.00%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c3633c6...46c4709. Read the comment docs.

Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fix looks good, but the issue it's fixing is about the import/no-unresolved rule

@ljharb ljharb force-pushed the patch-6 branch 2 times, most recently from 3a0c730 to 46c4709 Compare October 24, 2021 15:53
@ljharb ljharb merged commit 46c4709 into import-js:main Oct 24, 2021
@jablko
Copy link
Contributor Author

jablko commented Oct 25, 2021

Thanks!

My reading of #2267 is that the original import/no-unresolved issue was the intended behavior, and the outstanding issue raised by @Ulrikop was about the import/extensions rule, fixed by this PR?

@ljharb
Copy link
Member

ljharb commented Oct 25, 2021

hm, maybe so - i'll confirm with the OP.

glasser added a commit to apollographql/apollo-server that referenced this pull request Jun 24, 2022
So, Node requires generated ESM JS files need to have imports that end
with `.js` (unless they are importing the root or declared export from a
package... but for relative paths, this is a must). But we haven't quite
figured out a way to get tsc to force us to do this... so if we mess it
up, we only find out at runtime when trying to run a built ESM package.
This doesn't even necessarily show up in our tests (Jest does its own
thing a lot), and the new smoke-test doesn't cover all of our codebase.

So we set up eslint with a particular rule that looks for this. As it
happens, this rule doesn't check `import type`
(import-js/eslint-plugin-import#2270) but
fortunately `import type` doesn't matter to Node.

We don't generally enable eslint: there are plenty of rules that we
don't pass currently. We can consider adding some rules later as they
are found to be valuable. For now we just run this one rule!
glasser added a commit to apollographql/apollo-server that referenced this pull request Jun 24, 2022
So, Node requires generated ESM JS files need to have imports that end
with `.js` (unless they are importing the root or declared export from a
package... but for relative paths, this is a must). But we haven't quite
figured out a way to get tsc to force us to do this... so if we mess it
up, we only find out at runtime when trying to run a built ESM package.
This doesn't even necessarily show up in our tests (Jest does its own
thing a lot), and the new smoke-test doesn't cover all of our codebase.

So we set up eslint with a particular rule that looks for this. As it
happens, this rule doesn't check `import type`
(import-js/eslint-plugin-import#2270) but
fortunately `import type` doesn't matter to Node.

We don't generally enable eslint: there are plenty of rules that we
don't pass currently. We can consider adding some rules later as they
are found to be valuable. For now we just run this one rule!
glasser added a commit to apollographql/apollo-server that referenced this pull request Jun 24, 2022
So, Node requires generated ESM JS files need to have imports that end
with `.js` (unless they are importing the root or declared export from a
package... but for relative paths, this is a must). But we haven't quite
figured out a way to get tsc to force us to do this... so if we mess it
up, we only find out at runtime when trying to run a built ESM package.
This doesn't even necessarily show up in our tests (Jest does its own
thing a lot), and the new smoke-test doesn't cover all of our codebase.

So we set up eslint with a particular rule that looks for this. As it
happens, this rule doesn't check `import type`
(import-js/eslint-plugin-import#2270) but
fortunately `import type` doesn't matter to Node.

We don't generally enable eslint: there are plenty of rules that we
don't pass currently. We can consider adding some rules later as they
are found to be valuable. For now we just run this one rule!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants