chore: explicitly mark imports/exports that are only used as types

[wolfy1339]

---

Behavior

Before the change?

• Some compilers that don't fully parse typescript, ex: Babel and esbuild, would include these imports/exports in the build output

After the change?

• With the explicit markers, those imports/exports aren't included in the build output

Other information

---

Additional info

Pull request checklist

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
• Added the appropriate label for the given change

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes (Please add the Type: Breaking change label)
• No

If Yes, what's the impact:

• N/A

Pull request type

Please add the corresponding label for change this PR introduces:

• Bugfix: Type: Bug
• Feature/model/API additions: Type: Feature
• Updates to docs or samples: Type: Documentation
• Dependencies/code cleanup: Type: Maintenance

---

[oscard0m]

Should we lint this? https://typescript-eslint.io/rules/consistent-type-imports/ @wolfy1339

[wolfy1339]

It would be nice, but i don't think introducing another linter is the best idea

[oscard0m]

It would be nice, but i don't think introducing another linter is the best idea

Some extra step in test.yml maybe? Still creates friction to contributors, right?

[wolfy1339]

If it were a plugin for prettier, it would work just fine. Introducing eslint into the mix is probably not the best call.

For now, it will just have to be something to watch out for

[github-actions]

🎉 This PR is included in version 10.7.1 🎉

The release is available on:

• GitHub release
• npm package (@next dist-tag)

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 11.0.0-beta.8 🎉

The release is available on:

• GitHub release
• npm package (@beta dist-tag)

Your semantic-release bot 📦🚀