arlyon / stailwc

Tailwind in SWC, Nextjs, and Vite, fast 🚀
https://npmjs.com/package/stailwc
Apache License 2.0
230 stars 3 forks source link

tw global not defined in TypeScript #37

Open gpoole opened 1 year ago

gpoole commented 1 year ago

I'm having some issues with TypeScript since tw needs to be defined as a global. I can see stailwc.d.ts has the right types, but it's not included or exported in the published package. Should it be?

Looking in node_modules, this is the contents of my installed copy of stailwc 0.17:

node_modules/stailwc
├── CHANGELOG.md
├── LICENSE-APACHE
├── LICENSE-MIT
├── index.d.ts
├── install.js
├── package.json
├── readme.md
└── target
    └── wasm32-wasi
        └── release
            └── stailwc.wasm

4 directories, 8 files
arlyon commented 1 year ago

Sorry for the delay, I've been on holiday :surfer:

I currently don't export stailwc.d.ts and the recommendation is to just put that file into your project. It may make sense to just bundle it with the app but I am worried about that approach because it overrides things in the global namespace.

I typically use a types folder in my projects which contain any type overrides I need. Let me know what I can do in the docs to make this more clear :)

gpoole commented 1 year ago

No problem @arlyon, hope it was a good break!

I can see you've updated the docs to mention that now so that helps clarify. I agree with your concern about overriding globals at least in terms of the JSX stuff, and a conflict does happen in my case because the global css prop defined in stailwc.d.ts conflicts with the one for styled-components, so it's probably good to leave globals alone by default.

In terms of the tw global, my expectation as a user was actually that the package would export a typed tw function, like how twin.macro does for example. I was expecting to do something like this:

import { tw } from "stailwc";

<Example css={tw`block`} />

I think if you made the tw function a normal export, that would cover the bulk of what's in stailwc.d.ts, so the only thing left up to users to implement would be the tw and css JSX prop extensions.

For the tw and css props, if you haven't seen it, @types/styled-components I think gives a pretty clean (but not well documented :/) way to do this by making the JSX extensions an opt-in import that users can include with their other global definitions like this:

// global.d.ts
import 'styled-components/cssprop'

Since as I mentioned there is a potential conflict there for styled-components users maybe it's simpler to just leave that one up to users, or I suppose you could offer two versions of the import?

What do you think?

arlyon commented 1 year ago

I like that, actually. I deliberately left out tw from stailwc.d.ts because I prefer not having an import but that is a stylistic thing and we should support both. Perhaps we can add the tw function to the builtin types, as well as figure out a syntax for allowing direct import of the d.ts file, rather than having to copy and paste it.

I will mark this as a feature request and see if I have time to pick it up (unless you beat me to it 😏)