Compiling TypeScript with --declaration flag set results in an error

[brattonross]

Describe the bug
When compiling a TypeScript project with the --declaration flag set, given that the project also makes public some type that uses VariantProps, TypeScript will throw an error like:

Exported variable '' has or is using name 'ClassProp' from external module "" but cannot be named.

To Reproduce
Create a TypeScript project that exports a type that uses VariantProps in some way, and then try to compile with the --declaration flag set.

See repro here.

Expected behavior
There should be no error thrown.

This appears to be caused by ClassProp not being exported from the package

[joe-bell]

Seems like a duplicate of #5 – which I never really found out was the solution was 🤔

I think you just need to add skipLibCheck: true to your tsconfig.json? Could you confirm if this is true?

If so, I'll get something added to the README

[brattonross]

Ah I see, I didn't catch that other issue, and I get why you don't want to expose the interface.

Adding skipLibCheck: true doesn't appear to fix the issue for me, but I will have a play and see if I can figure out if there is a way to make TS happy

[brattonross]

Just for context, the use case for setting declaration: true for me is a reusable component library that comes with type definitions for components.

I have a feeling that this issue cannot be solved by changing a tsconfig option (apart from setting declaration to false), I've tried changing various options related to emit that I think might affect the issue, but not had any success.

Whilst my typescript knowledge is definitely not perfect, from what I can gather, ClassProp is sort of inherently part of the public API of the package. This is because it is part of the type declaration of the cva function. It not being exported means that the typescript compiler cannot do its job when declaration is set, because it needs to be able to get hold of that type to create the type definitions, but it can't because it isn't exported.

I am also fairly certain that we'd see the same issue appear for VariantsConfig or VariantsSchema if they were interfaces instead of types, because this issue doesn't seem to affect types for some reason.

I'm sort of convinced at this point that exporting the types is the correct thing to do, but I also want to respect your decision as the maintainer if you want the package API to be a certain way.

A benefit of exporting the types is that it makes it easier to extend on cva. For example, I spend most of my time with React, so when using cva I will have to map the className prop to the class prop. It would be nice if I could use those types to make my own cva wrapper that takes className instead. Whilst I'm sure it is possible currently, it would be easier if the types that make up cva were made available.

[joe-bell]

OK I think I've found a quick-fix; it's a little annoying but it works fine

[joe-bell]

Published under version 0.2.1-canary.1. Let me know if this works alright for you?

[joe-bell]

Tested with you repro; seems to work great