chore(Table): refine ActionsColumn warning

[kmcfaul]

Now will issue a warning, and only if both the Table import and ActionsColumn/DropdownToggle are also imported.

[gitdallas]

I wonder if we should continue using importDeclaration so we can point the codemod report to the line number of the import declaration.

also, @thatblindgeye - curious how this will work in relation to #344

on first pass without fix... their code will likely be pointing to DropdownToggle in react-core which in v4 was what will be react-core/deprecated in v5... will trigger both these codemods.. fine? Then after running a fix, it will point to "deprecated" and this one shouldn't be triggered (at least by the table+dropdownToggle)

[thatblindgeye]

on first pass without fix... their code will likely be pointing to DropdownToggle in react-core which in v4 was what will be react-core/deprecated in v5... will trigger both these codemods.. fine? Then after running a fix, it will point to "deprecated" and this one shouldn't be triggered (at least by the table+dropdownToggle)

That sounds accurate to me. Whichever one (this or 344) gets in last we can double check that though in the test.tsx file and tweak things from there if needed.

[kmcfaul]

@gitdallas @thatblindgeye Swapped back to ImportDeclaration. The rule will fire twice with this configuration (once per core imports and table imports) but will be more specific than Program.

[gitdallas]

@thatblindgeye @kmcfaul an update on how it looks with the dropdown deprecation:

running the fix will clear the codemod errors/warnings look like this:

should this issue also (only?) check for dropdown from the /deprecated import path?

might have to say the same for isPrimary (even though in this case it was lucky and fixed the attribute before changing the import) and look for others

[thatblindgeye]

should this issue also (only?) check for dropdown from the /deprecated import path?

Maybe...? If we're not trying/expecting for the fix flag to fix everything with a single pass, then it may not be a bad idea to only target the deprecated path.

[kmcfaul]

Wouldn't that mean the order that the codemods run in will matter then? Because the codemod to update the deprecated path would have to run its fix before this codemod would detect the conditions to warn the user about the mismatch. I could update the codemod to look in both directories maybe, or am I overthinking this?

Edit: updated to look in both import locations

[gitdallas]

Wouldn't that mean the order that the codemods run in will matter then?

we may run into this situation.. v4 codemods have a similar issue in card-rename-components where the renames were as such:

const renames = {
  'CardHeader': 'CardTitle',
  'CardHead': 'CardHeader',
  'CardHeadMain': 'CardHeaderMain'
};

so CardHeader exists both before and after... but differently. They solved the issue by adding a data-codemods attribute. We may have to consider this at some point if we have situations where we can't differentiate otherwise.