Any thoughts around import/no-extraneous-dependencies?

[slifty]

I love this project (I hope you get this a lot)

I'm cleaning up a legacy eslint config and we're generally trying to adopt community standards and minimize our local overrides.

That said, we had import/no-extraneous-dependencies enabled and I was curious what the love team thought about the rule, since it isn't enabled by your config at the moment. I'm mostly curious if it is intentionally omitted on your end (e.g. this functionality already covered by another rule, the rule is unhelpful, or the rule requires local context to be properly configured e.g. devDependency options) or if it would be desired.

At a glance of the documentation it seemed to be useful.

[mightyiam]

Thank you, @slifty! There's no team, by the way. It's just me and I've been busy with Nix related work. But I try to keep this up to date.

The rule seems like a good candidate to me. Would you be interested in adding it?

[slifty]

Awesome -- I'd be glad to contribute it! Not ready to commit to joining a mob session just yet (not for lack of interest, just time) but I'll open a PR for sure.

[slifty]

Since nothing is ever truly simple I wanted to raise a design question (this rule has some options):

devDependencies: If set to false, then the rule will show an error when devDependencies are imported. Defaults to true. Type imports are ignored by default.

optionalDependencies: If set to false, then the rule will show an error when optionalDependencies are imported. Defaults to true.

peerDependencies: If set to false, then the rule will show an error when peerDependencies are imported. Defaults to true.

bundledDependencies: If set to false, then the rule will show an error when bundledDependencies are imported. Defaults to true.

Using the defaults would for sure still an improvement -- the rule would at least require an import to appear directly in package.json.

That said, the following would be even tighter, at the expense of being potentially narrower:

1. optionalDependencies: false :: optionalDependencies overall this concepts seem fairly fringe to me; this would basically mean they aren't allowed, which might be OK since it can be override.

2. devDependencies: { ... a series of common dev patterns e.g. test / story / mock files } :: without this setting a project could still accidentally import a non-type devDependency into a production / code file. I wouldn't want to generally enable this setting (e.g. false) since for things like mocks, test files, scripts, and stories devDependency imports are expected.

An example devDependencies pattern set could be something like:

  "devDependencies": [
    // tests
    "**/__tests__/**",
    "**/*.test.*",
    "**/*.spec.*",
    "**/*.e2e.*",

    // examples/demos
    "**/*.stories.*",
    "**/*.story.*",
    "**/*.demo.*",
    "**/*.examples.*",
    "**/*.mdx",

    // local tooling & scripts
    "**/scripts/**",
    "**/tools/**",

    // config files of any build/test tool
    "**/*.{config,setup,conf}.*,

    // fixtures & mocks
    "**/__mocks__/**",
    "**/fixtures/**",
    "**/mocks/**"
  ],

The question, is whether the above list is too bespoke for a community ruleset / whether we should just do the "bare minimum" as the love default, leaving it to users to regularly override.

I personally would want to target a rule attempts to create the safest possible lint settings that works for the majority of cases, and either (A) let folks override if the defaults don't align with their projects non-standard naming convention or (B) let folks open PRs if the configuration doesn't account for a standard naming convention.

[mightyiam]

I think we should go for quite a strict configuration and see what our users complain about.