Closed OmgImAlexis closed 1 year ago
Copy-pasting from https://github.com/egoist/tsup/issues/14#issuecomment-630227883:
Sometimes the things from @types
have really strange idioms in them, and its a nightmare to work with.
This example in particular. I think, this is whats going on:
namespace
as an opaque "item". Due to declaration merging, you can have namespaces which have the same name as functions, which is basically the same as having an interface with members and a call signature.module.exports = fn_with_props
require
that, since the result is just any kind of value..d.ts
world. And TBH, I don‘t want to, since its something that is fundamentally different when using ES modules.I agree, let's support the ES Module future and not dwell on CommonJS pitfalls.
Hi, is this still an issue? I'm hitting problems when using tsup because of various sub-dependencies using export =
in their .d.ts files, and I'm unsure what's needed to solve it.
This is still not supported, and I doubt I will add support for this myself. PRs welcome of course.
The question here would rather be: Why are you trying to bundle your sub-dependencies in the first place?
I don't think I am. But I'm not sure. I'm trying to add a feature into Storybook, which has recently started using tsup. Importing types from fastify
is breaking the build, apparently because of this issue. What configuration would I need to look for to see whether or not sub-dependencies are being bundled? I've not worked with tsup before, and I don't have a great grasp of how it's all working right now.
I've not worked with tsup before, and I don't have a great grasp of how it's all working
Neither have I 🤷🏻♂️
My plugin ignores external dependencies by default.
Is it possible to make the output d.ts file using export =
format to support both ESM and CJS?
Ref: https://github.com/egoist/tsup/issues/14#issuecomment-630220268