Skip to content

Conversation

@lunelson
Copy link
Contributor

@lunelson lunelson commented Nov 28, 2025

This POC is for practical testing of figma variable export approaches, and for converging with Ciaran H on a variables and variations naming structure in Figma that we can rely upon for clean parsing to PandaCSS' theme configuration pattern

NOTE: a number of the files here were created by the tsdown template for React component libraries

@lunelson lunelson changed the title Stub a Figma-to-Panda POC [H-5723] Stub a Figma-to-Panda POC Nov 28, 2025
@vercel
Copy link

vercel bot commented Dec 1, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
petrinaut-hazel Ready Ready Preview Comment Dec 2, 2025 8:51am


## TODOs

- [ ] establish coordinatedthe variables nomenclature in Figma
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly this? Wasn't sure what the @todo actually meant. I suspect this may now also be done post-pairing w/ CH?

Suggested change
- [ ] establish coordinatedthe variables nomenclature in Figma
- [ ] establish the variables nomenclature in Figma

Comment on lines +1 to +4
node_modules
dist
*.log
.DS_Store
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't matter in the labs dir, but for awareness in the main hash monorepo we try to avoid having nested ignore files, and define everything in the root .gitignore which we then selectively sync with our other ignore files (also in the root) which handle linting exceptions, etc. This helps us keep things manageable in the monorepo structure.

In this case these 3 of these 4 appear in the root .gitignore already, with the exception of the *.log command (which the existing root .config/**/*.log exclusion could simple be expanded to account for).

Copy link
Contributor Author

@lunelson lunelson Dec 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can aim for that, but I would say the upside of nested ignore files is that you keep the file closer to the relevant patterns it is ignoring, which makes it easier to understand what is being ignored where and why, and allows the patterns to be more targeted (e.g. absolute paths relative to the nested file)—plus you avoid potentially unclear (or eventually orphaned) patterns in the root file.

FTR there are currently 7 nested .gitignore files in hash other than the root one

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No disagreement on those points; IIRC this was a conscious architectural decision for least a couple of reasons, although likely more I'm forgetting:

  1. (At least at the time) not all of our ignore files supported existence outside of the root. Possibly still true but we haven't checked in years and the exact ignore files we have may even have changed since.
  2. We wanted to improve keeping our various ignore files in sync, and sharing elements between them (which was a real pain point).

Stray .gitignores may well have slipped in to the primary public monorepo, but I wanted to flag this as an explicit goal since I am aware it exists, and know you would otherwise not have context on it (yet).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants