Open mgol opened 11 months ago
To be clear, this still works with "moduleResolution": "node10"
(or "node"
which is just a deprecated alias of "node10"
now) but if you try "node16"
or any other modern setting, the exports
field is consulted and the above problem appears.
Any news on this?
Yeah, I'd also like to throw a vote for supporting this sooner rather than later. I would like to start using sub-path exports, but as soon as I turn on moduleResolution: bundler
in an application that has Cypress e2e, I start getting Cannot find module 'cypress/types/net-stubbing' or its corresponding type declarations.
Any update or workaround on this ?
Any updates or plans for fixing this issue?
What would you like?
We have a lot of imports like:
in the app.
This used to work fine until I tried to update TypeScript to a version that properly parses the
exports
field (5.2 but I think all >=5.0 might behave in a similar way) inpackage.json
, which for Cypress contains sub-entries like:Since there's no entry starting with
./types
, you can't import from this file like that.That may be fine but importing directly from
cypress
doesn't work:This happens for two reasons. First,
types/cypress-npm-api.d.ts
declares thecypress
module and imports ofcypress
lead to it. This can be hacked around by importing fromcypress/
instead:but
types/index.d.ts
is not a module - it does not import or export anything directly, it just has a bunch of pragmas like:It seems all the types are supposed to do is to type the built-in globals.
Why is this needed?
A lot of the types Cypress defines are useful for external consumers, e.g. to build custom interceptors, etc. It doesn't seem like there's a way to use the provided types with new TypeScript. Right now, it seems my choices are either hacking the
cypress
package to export what I need or to redefine all the types in the project - which may be quite daunting as they can get pretty complex.Other
No response