[no-duplicates] prefer-inline should merge type and non-type imports

[latin-1]

Input:

import { A } from "./mod";
import type { B } from "./mod";

Output:

import { A, type B } from "./mod";

[latin-1]

There is also a regression in 2.27:

Input:

import { A } from "./mod";
import { type B } from "./mod";

Output:

// 2.26
import { A, type B } from "./mod";

// 2.27
import { A } from "./mod";
import { type B } from "./mod";

I opened another issue for this regression: #2677

[latin-1]

cc @snewcomer

[snewcomer]

@latin-1 I'm also seeing this. Thank you. At one time, I applied all these changes to the ember.js repo and to a large API and everything worked swimmingly. However, I think it was when everything was bundled up in this PR before we split it up. I don't clearly remember. I do plan on looking at this this week.

[simmo]

I might be mistaken, but I think the docs might be wrong. As I understand it, it is supposed to be ["error", "prefer-inline"] to align with import/consistent-type-specifier-style, but the only allowed syntax is ["error", {"prefer-inline": true}]. I'm easy either way just thought I'd flag it 😄

[ljharb]

@simmo that doesn't seem right - the schema is clear that it's a string, not an object. Are you sure you're using the latest version of the plugin?

[simmo]

Yep I'm using 2.27.5. It allows object syntax but not string.

[ljharb]

ohhh yes, that's correct, they have a different schema (i was checking consistent-type-specifier-style).

I don't think it's worth adding a string overload for no-duplicates, nor an object overload for consistent-type-specifier-style, but I agree it ends up being an inconsistency. If the docs are wrong, a PR to fix them would be appreciated!

[simmo]

If the docs are wrong, a PR to fix them would be appreciated!

My pleasure 😄 - PR for documentation #2684