feature request: add ignore options for `import/no-duplicates`

[JounQin]

When using TypeScript with date-fns, it only has one bundled typings.d.ts, so eslint-import-resolver-ts will resolve all modules to it.

But they are not all exported from date-fns, what means date-fns and date-fns/locale are different.

So we should allow this case by whitelist.

[ljharb]

This seems like an inherent flaw in resolving a module to a d.ts file that might represent multiple files. I don’t think forcing an allowlist is an elegant solution; I’d prefer to find a better one.

[JounQin]

If we do have a better one, that will be greater.

[JounQin]

@ljharb Any news on this. If we don't have a better solution, an option for whitelist maybe considered?

[ljharb]

Rereading the OP, it kind of seems like it’s just a bug in date-fns’ typings file?

[JounQin]

Why do you think it's a bug of date-fns? It's valid usage of .d.ts files.

[ljharb]

But they are not all exported from date-fns, what means date-fns and date-fns/locale are different.

[JounQin]

.d.ts are fine to be declared in one file for multiple sources. It valid and TypeScript itself doesn't complain. So it's just a choice.

[ljharb]

If the types in date-fns are correct, then eslint-import-resolver-ts (eslint-import-resolver-typescript is the one i recommend, incidentally) should be resolving them properly.

I'm still confused what the issue is. Are you saying that because date-fns and date-fns/locale resolve to the same type file, they're considered as duplicate imports?

[JounQin]

import * from 'date-fns'
import * from 'date-fns/locale'

The above import statements both resolves a same typings.d.ts which include

declare module 'date-fns' {
  // ...
}

declare module 'date-fns/locale' {
  // ...
}

[JounQin]

Are you saying that because date-fns and date-fns/locale resolve to the same type file, they're considered as duplicate imports?

Yes, that's the point.

[ljharb]

It doesn’t seem right to me that they should resolve to the location of their types, so that seems like something that should be fixed in the resolver.

[JounQin]

What's the problem of the resolver? We may import types from the pkg, there is no types in .js sources, so .d.ts files are preferred.

[ljharb]

Yeah, i can see the difficulty. I’m not sure how we’d solve this properly. An exclude list seems like a workaround.

[JounQin]

An exclude list seems like a workaround.

So is this accepted? I can raise a PR if so.

[ljharb]

Given that most packages do the right thing, and don't ship types directly but rather use DT, and given that this is a potential problem with any package that chooses to conflate its API's semver with the semver of its types, I'd prefer to not add an exclude list and instead seek a true fix.

[JounQin]

So we need to support resolve .d.ts with original .js source at the same time, right?

[ljharb]

I think that is the challenge, yes.

[wcastand]

Hi, we have the issue where --fix merge both:

import { format } from 'date-fns';
import fr from 'date-fns/locale/fr';

is merged into

import fr, { format } from 'date-fns';

Is there a way to avoid this since the last msg is from more than a year ago? Right now we have to disable eslint on it which doesn't really look like a solution :/

[natterstefan]

Hi @wcastand,

our workaround for this, until its solved, looks like this:

/* eslint-disable import/no-duplicates */
import formatDate from 'date-fns/format'
import enGB from 'date-fns/locale/en-GB'
import de from 'date-fns/locale/de'
/* eslint-enable import/no-duplicates */

I hope this helps.

[wcastand]

yeah we went with a ignore next line on each line but it's not really a solution to me. thanks for sharing still :)

[manfrinmm]

This was my temporary solution:

import { differenceInDays, format, startOfDay, startOfToday } from "date-fns";
import * as locale from "date-fns/locale";

...

const { ptBR } = locale;

[lucasdu4rte]

@manfrinmm import * as locale from "date-fns/locale" imports all locales available in date-fns, increasing the build size.

that's my temporary solution:

// locale/dateFns.ts
import ptBRLocale from 'date-fns/locale/pt-BR';

export { ptBRLocale };

// other files
import { ptBRLocale } from './locale/dateFns';

[trajano]

at this rate especially because of this bug I think using something that utilizes the typescript language server may be more prudent (e.g. prettier-plugin-organize-imports). I just got dinged by this when I was setting up the ESLint rules for my monorepo

[alexilyaev]

Another simple use-case:

import format from 'date-fns/format';
import differenceInHours from 'date-fns/differenceInHours';
import orderBy from 'lodash/orderBy';
import get from 'lodash/get';

'.../node_modules/date-fns/typings.d.ts' imported multiple times

Would love to have an options to exclude some packages or patterns from the check

[mvshmakov]

A temporary workaround can be to use eslint-plugin-local and define a custom post-processor:

plugins: ['local'],
processor: 'local/suppress',

Then, to create a .eslintplugin.js file in the root of the project with the following content:

module.exports = {
  processors: {
    suppress: {
      postprocess: (messages) => {
        const [message] = messages.map((violations) =>
          violations.filter(
            (violation) =>
              !violation.message.endsWith(
                "date-fns/typings.d.ts' imported multiple times."
              )
          )
        )
        return message
      }
    }
  }
}

But a proper support of it is still highly desirable. Either with an array of excludes, or a proper support on the resolver level.

[EmCeeEs]

Same thing happens with svelte:

  import { onMount } from "svelte"
  import { slide } from "svelte/transition"

will be fixed to yield

  import { onMount, slide } from "svelte"

[ShadiestGoat]

Same problem here. Would love a resolution!

This can probably be paired with eslint-import-resolver-typescript#197 as a 'refactor the way .d.ts modules are handled' issue

[JounQin]

This can probably be paired with https://github.com/import-js/eslint-import-resolver-typescript/issues/197 as a 'refactor the way .d.ts modules are handled' issue

You will meet this issue more often if custom .d.ts with declare is supported.

[ShadiestGoat]

This can probably be paired with https://github.com/import-js/eslint-import-resolver-typescript/issues/197 as a 'refactor the way .d.ts modules are handled' issue

You will meet this issue more often if custom .d.ts with declare is supported.

Not if its properly supported

[JounQin]

I may do some prototypes on https://github.com/un-es/eslint-plugin-i