Ast module resolution

packages/react-components/token-analyzer-preview/library/README.md

@@ -4,19 +4,26 @@ A static analysis tool that scans your project's style files to track and analyz
 
 ## TODO
 
+- we also need to ensure var analysis is done correctly after the refactor
+- ~~**This is high pri now since we have components in source using this technique (see buttonstyles.styles.ts)** Handle very complex cases like `var(--optional-token, var(--semantic-token, ${some-other-var-with-a-string-or-fallback}))`. This other var might be in another package or file as well. Currently we won't handle this level of depth but we could do symbol extraction in the future if needed to resolve the chain fully. This will likely require changes in importAnalyzer.ts and structural changes in the data we return. On top of needing to find referenced symbols within an aliased template string literal, we might also then need to parse out var fallbacks within short hands. IE: `padding: 'var(--first, var(--second)) 10px` and ensure the ordering is correct.~~
+- ~~Format output with prettier when we save to ensure stage lint doesn't fail.~~
+- ~~make sure this works with shorthand spread~~
+- Look at the path info again. Do we ever need it?
+- Convert token member within the analysis output to an array so we can hold multiple tokens. The order should be the order or priority. [0] being the highest pri with the last item in the array the least prioritized.
+- Duplicate entries in useButtonStyles.styles.ts for useRootDisabledStyles.base.nested:hover.color - we might need to test case this
+- ~~We've added the ability to analyze spreads but there's an issue where we find the tokens and call them out but they get nuked somewhere before we return them. Need to trace that and fix.~~
+- Add makeResetStyles specific tests in analyzer to ensure we process those correctly.
+- ~~Button has some weird patterns in it where it uses makeResetStyles and then uses enums to pull in the styles, we might need to account for those as well.~~
 - ~~Some property assignments can also be function calls, we need to process this scenario~~
 - ~~`createCustomFocusIndicatorStyle` is a special function that is used throughout the library so we might be able to special case it~~
-- if we have file imports we need to analyze those such as importing base styles
-- we also need to ensure var analysis is done correctly after the refactor
+- ~~if we have file imports we need to analyze those such as importing base styles~~
   ~~- Manage makeResetStyles (likely same as makeStyles)~~
-- Button has some weird patterns in it where it uses makeResetStyles and then uses enums to pull in the styles, we might need to account for those as well.
 - ~~what if we have multiple `makeStyles` calls merged, are we handling that correctly or just nuking the conflicts in our output?~~
-- make sure this works with shorthand spread
 - as we update the functionality, we should update our test cases to reflect the new functionality we support and ensure it works.
 - ~~if we have functions we can't process (or other code for that matter), can we add that data into our report so we know to manually go deal with it?~~
 - ~~assignedSlots in output to track which slots classes are applied to~~
 - ~~Add variables full name to metadata (i.e. classNames.icon instead of just 'icon)~~
-- Module importing
+- ~~Module importing~~
 
 ## Features