After the Figma changes, we have a different way of storing tokens, and they're all in one folder. We haven't needed the multiple input directories for a while, and we don't really have a big reason to run the command multiple times for different outputs either. This command has become specific to outputting what our other packages will consume, while we have a separate set of scripts for syncing with Figma.

…e broadly useful

We will now need them in the CSS/Sass exporters

Let the Figma scripts do the conversion from `.` to `/`, but let our other exporters expect the alias notation to match the flattened keys

by breaking it into functions that are easier to test and by only converting the files it finds rather than requiring all theme files to be present

Still need to resolve values more intelligently and generate variable names in a way that matches the old ones and conveys the correct hierarchy

The test data needs some layout tokens, but it gets complicated, because spacers are currently defined as plain numbers in Figma, whereas we'll probably want the JSON `$type` to be `dimension`. We need to intelligently convert the values between our JSON storage and Figma

Once we do our first down-sync from Figma, we could possibly start storing this translation information as meta-data inside the JSON tokens. It wouldn't get uploaded to Figma, but it could be manually maintained in our repository. Being able to store information that doesn't go to Figma, however, would require that we merge incoming data with our local JSON files instead of the current overwriting method.

Actually, if we're not storing that info in Figma, it's already in our tokens...why would I have to tell a dimension token that it's a dimension? If we don't need to be able to save the JSON based on only the information stored in Figma, then this isn't a problem at all. Maybe after the first down-sync we just need to update the down-sync operation to be a merge, and we look at the local (repository) token's `$type` and `$value` properties before converting from our Figma `NUMBER` variable. If `$type` is `dimension` then look at the unit of `$value` to determine how to translate from Figma.

This is so fiddly. I hate it.

We don't have the full set of tokens in Figma yet because we're in the process of trying to transfer the library file from one account to another, but we've got all the `System` variables, and I manually created a few variables in the `Theme` collection.

If a variable is an alias, we don't need to send it through our logic for converting pixel values to other units

My previous solution wasn't perfect because it didn't account for inheriting the token type from the aliased variable

I now that I think about it again, I don't really think it's necessary to store the number type information in the `$extensions` when we can later infer from the `$type` and the converted `$value` string that it wrote, which should contain the unit. The only weird one would be `0` values that are also `dimensions`, but I say we always pretend those are pixel values.

Now that we don't duplicate the type information on alias tokens, we have to resolve the aliases until we get to a real token with a type in order to send that information to Figma.

… fail

They will fail because I've manually created the snapshots by copying the old CSS files so we can see the changes from this branch

…pshots

Following the example of figma/variables-github-action-example#19