chore: allow type only imports for 'mongodb' package in connection-form

[himanshusinghs]

Description

This is a follow up for the PR-5197 where we moved 'mongodb' to devDependencies in connection-form. In this PR we are restricting imports from 'mongodb' package to type only to avoid any possible regression in future.

Checklist

• New tests and/or benchmarks are included
• Documentation is changed or added
• I have signed the MongoDB Contributor License Agreement (https://www.mongodb.com/legal/contributor-agreement)

Motivation and Context

• Bugfix
• New feature
• Dependency update
• Misc

Open Questions

Dependents

Types of changes

• Backport Needed
• Patch (non-breaking change which fixes an issue)
• Minor (non-breaking change which adds functionality)
• Major (fix or feature that would cause existing functionality to change)

[himanshusinghs]

After checking the docs again, I figured that this won't work with inline type imports.
The other rule that I tried was no-restricted-syntax but that suffers from the same problem, does not work on inline type imports.

Now I could try writing a custom rule but I think we should probably get consistent with how we import types. What do you guys think?

[gribnoysup]

Can you clarify a bit what do you mean by inline type imports and where this would cause an issue?

[himanshusinghs]

By inline I meant this:

import { type X } from 'package-y';

We were earlier using the following syntax:

import type { X } from 'package-y';

but lately I saw a lot of usage of the inline type imports which sounds ok (maybe better in the way that they at-least allow import declaration of the package only once) but unfortunately that syntax fails for all the rules (no-restricted-syntax, no-extraneous-dependencies, no-restricted-imports) that I tried while attempting this restriction.

[gribnoysup]

Gotcha, thanks for context. IIRC this is mostly coming from eslint autofix and eslint autofixes to import { type <name> } only in cases where a mixed import is possible, so I wouldn't worry too much about it. The benefit of not accidentally pulling a non-type import for a package that we don't want to have in runtime seems to outweight the downside. Also this just seems like eslint plugin not being caught up with the new syntax, so it probably will eventually go away

[himanshusinghs]

Yea that sounds about right, the plugin would eventually get updated. Alright I will keep it as is. Thank you :)

[gribnoysup]

I think connection storage was another one that we only want as type-only dep here, right?

[himanshusinghs]

Thank you, I overlooked this one - added this in 247e5ca