Request to ship both cjs & esm

[hkleungai]

Hello @frenic , I notice that the latest v3.2.0 release is shipping esm-only typedef. Is it possible to have another update, so that both cjs & esm can be shipped together? This would benefit downstream packages by letting them importing the latest css type without having to migrate old cjs codebase into an esm one.

Just a note. I have done a very naive trial on upgrading csstype on DefinitelyTyped. See the result here. Most of the affected packages are failing CI due to cjs-esm interop issue. I suppose they can be avoided if csstype can support both cjs & esm nicely :)

[frenic]

Sure I changed to "type": "module" in package.json and I suspect that has something to do with it. I didn't think it would have an impact because this package doesn't have any exports. It's just types that doesn't compile to anything using neither cjs nor mjs. But I will revert it if it causes problems. I can convert .js files to .mjs instead.

[frenic]

Hope v3.2.1 works better?

[hkleungai]

Sure. Let me give a try 👍

[hkleungai]

Most of them works fine in the latest test. I think it is a good sign, for the community to have a chance to embrace this latest version.

There is still a CI failure though, in here. Looks like DataType.FinalBgLayer is missing (or gone) in the latest version, and it in turn erases the generic-ness from Property.Background.

I checked a bit. Seems at v3.0.2 we still have generic Property.Background & DataType.FinalBgLayer in place.

I wonder, is the removal of DataType.FinalBgLayer an intentional one? Does the mdn data have an update that is causing the change? 🤔

[frenic]

Wow, that was odd. Thank you for noticing. Something new was added to the syntax for background that the interpreter didn't understand. Is fixed in 3.2.2.

[hkleungai]

Everything on DefinitelyTyped works as expected now. I suppose we can happily close this issue.

A big thanks to your help. 🚀

[joaopedrodcf]

Should we reopen this issue @frenic as I saw the change to be ESM has reverted in the following commit c3a6cc1, I would be available to help if you want 🙏

[frenic]

Sure, it would be nice to have some help on this one. Maybe take some inspiration from any @types. This issue just feels odd because it's only a d.ts that's handled internally in Typescript and shouldn't be depended on any export variant. But I guess it's because most build systems and tools expects some kind of runtime code.

[hkleungai]

FYR, there are plenty of resources to guide one on shipping cjs & esm dual build. e.g. this one, which has a typescript-related section in the middle.

In csstype case, in my opinion, no matter how the pipeline on this project evolves, it would be better for the final type-build to always include cjs. In this way, older (web) projects which stuck in cjs forever can safely and easily migrate to any latest csstype version as needed.