fix(imports-as-dependencies): check within exports for types #1579
Conversation
| 🎉 This PR is included in version 61.1.6 🎉 The release is available on: Your semantic-release bot 📦🚀 |
| if (!pkg || (!pkg.types && !pkg.typings)) { | ||
| if (!pkg || (!pkg.types && !pkg.typings && !resolve.exports(pkg, '.', { | ||
| conditions: [ | ||
| '!default', '!import', '!node', 'types', |
There was a problem hiding this comment.
Hi, I was following the !default discussions where you posted recently but I'm not up to date with this project so my comment may not apply.
I just wanted to let you know that by excluding with !import, due to the way that resolve.exports (and your fork) works, you may be missing some types conditions defined either inside an imports object (eg, https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-7.html#packagejson-exports-imports-and-self-referencing or https://www.typescriptlang.org/docs/handbook/modules/reference.html#example-explicit-types-condition) or as a types object (eg, https://app.unpkg.com/ts-api-utils@2.1.0/files/package.json#L17).
There was a problem hiding this comment.
Thank you for this. Not sure about imports, but for the types object, it seems we would need to add support for hierarchical conditions to resolve.exports.
This rule also misses types defined as globals or based solely on file path.
I think we need separate issues to track these things. Do you care to file one?
There was a problem hiding this comment.
I've submitted a new feature which only checks for types, but also respects nesting. Thanks again for the report!
There was a problem hiding this comment.
Thank you for adding the types utility to your fork!
2 participants
fix(
imports-as-dependencies): check withinexportsfor types; fixes #1114