chore: added eslint plugin import check on missing dependencies

[Rajdeepc]

Description

Added eslint-plugin-import plugin to check for extraneous dependencies.

Related issue(s)

• @spectrum-web-components/styles@1.0.0 importing lit in several places, but doesn’t depend on it and is missing lit as its direct dependencies causing compile errors

Motivation and context

How has this been tested?

• Test case 1

  1. download the branch
  2. run yarn lint

• Did it pass in Desktop?

• Did it pass in Mobile?

• Did it pass in iPad?

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (minor updates related to the tooling or maintenance of the repository, does not impact compiled assets)

Checklist

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• If my change required a change to the documentation, I have updated the documentation in this pull request.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have reviewed at the Accessibility Practices for this feature, see: Aria Practices

Best practices

This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against main.

[github-actions]

Branch preview

• Documentation Site
• Storybook

[github-actions]

Tachometer results

Currently, no packages are changed by this PR...

[coveralls]

Pull Request Test Coverage Report for Build 11947981002

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 5 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.008%) to 98.189%

---

Files with Coverage Reduction	New Missed Lines	%
packages/dialog/src/DialogBase.ts	5	93.33%

Totals
Change from base Build 11795977313:	-0.008%
Covered Lines:	32358
Relevant Lines:	32778

---

💛 - Coveralls

[github-actions]

Lighthouse scores

Category	Latest (report)	Main (report)	Branch (report)
Performance	0.99	0.97	0.98
Accessibility	1	1	1
Best Practices	1	1	1
SEO	1	0.92	0.92
PWA	1	1	1

What is this?

Lighthouse scores comparing the documentation site built from the PR ("Branch") to that of the production documentation site ("Latest") and the build currently on main ("Main"). Higher scores are better, but note that the SEO scores on Netlify URLs are artifically constrained to 0.92.

Transfer Size

Category	Latest	Main	Branch
Total	250.915 kB	236.596 kB 🏆	236.73 kB
Scripts	60.522 kB	54.15 kB 🏆	54.278 kB
Stylesheet	54.126 kB	47.906 kB 🏆	47.964 kB
Document	6.222 kB	5.465 kB 🏆	5.468 kB
Font	127.017 kB	126.632 kB 🏆	126.633 kB

Request Count

Category	Latest	Main	Branch
Total	52	52	52
Scripts	41	41	41
Stylesheet	5	5	5
Document	1	1	1
Font	2	2	2

[blunteshwar]

Certain tests are failing. Once we rectify them I think we are good to go!

[rubencarvalho]

We need to check multiple things:

1. It would be best if we applied the same rule across the entire project. Currently, this only applies to ./tools/*, but we also have a root-level eslintrc.json file.
2. If we apply it globally, I’d say projects/documentation is safe to ignore.
3. This change will likely trigger numerous linting errors, which should be addressed within the scope of this PR.
4. Can we check if switching to JS-based ESLint configs (instead of JSON) might better support the required changes? This would allow us to add more complex path/package-parsing logic if needed.