Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix(deps): update linters #439

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

fix(deps): update linters #439

wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Dec 1, 2024 •
edited
Loading

This PR contains the following updates:

Package Change Age Adoption Passing Confidence Type Update
eslint-import-resolver-typescript ~3.6.3 -> ~3.7.0 age adoption passing confidence dependencies minor
eslint-plugin-eslint-comments ~3.2.0 -> ~3.2.0 dependencies replacement
eslint-plugin-import-x ~4.4.3 -> ~4.5.0 age adoption passing confidence dependencies minor
eslint-plugin-jsdoc ~50.5.0 -> ~50.6.0 age adoption passing confidence dependencies minor
eslint-plugin-n ~17.14.0 -> ~17.15.0 age adoption passing confidence dependencies minor
eslint-plugin-promise ~7.1.0 -> ~7.2.0 age adoption passing confidence dependencies minor
eslint-plugin-testing-library ~7.0.0 -> ~7.1.0 age adoption passing confidence dependencies minor
prettier (source) 3.3.3 -> 3.4.2 age adoption passing confidence devDependencies minor

This is a special PR that replaces eslint-plugin-eslint-comments with the community suggested minimal stable replacement version.

Release Notes

import-js/eslint-import-resolver-typescript (eslint-import-resolver-typescript)

v3.7.0

Compare Source

Minor Changes

  • #​326 93ea130 Thanks @​SukkaW! - This version has implemented the eslint-plugin-import-x's v3 resolver interface. This allows you to use import/require to reference eslint-import-resolver-typescript directly in your ESLint flat config:

    Previously

    // eslint.config.js
module.exports = {
  settings: {
    'import-x/resolver': {
      typescript: {
        alwaysTryTypes: true,
      },
      // or
      require.resolve('eslint-import-resolver-typescript'):
        alwaysTryTypes: true,
      }
    }
  }
}

    Now

    // eslint.config.js
const {
  createTypeScriptImportResolver,
} = require('eslint-import-resolver-typescript')

module.exports = {
  settings: {
    'import-x/resolver-next': [
      createTypeScriptImportResolver({
        alwaysTryTypes: true,
      }),
    ],
  },
}

    Note that this only works with eslint-plugin-import-x@>=4.5.0. You can't use createTypeScriptImportResolver with the older versions of eslint-plugin-import-x or any existing versions of eslint-plugin-import.

un-ts/eslint-plugin-import-x (eslint-plugin-import-x)

v4.5.0

Compare Source

Minor Changes
For eslint-plugin-import-x users

Like the ESLint flat config allows you to use js objects (e.g. import and require) as ESLint plugins, the new eslint-plugin-import-x resolver settings allow you to use js objects as custom resolvers through the new setting import-x/resolver-next:

// eslint.config.js
import { createTsResolver } from '#custom-resolver';
const { createOxcResolver } = require('path/to/a/custom/resolver');

const resolverInstance = new ResolverFactory({});
const customResolverObject = {
  interfaceVersion: 3,
  name: 'my-custom-eslint-import-resolver',
  resolve(modPath, sourcePath) {
    const path = resolverInstance.resolve(modPath, sourcePath);
    if (path) {
      return {
        found: true,
        path
      };
    }

    return {
      found: false,
      path: null
    }
  };
};

module.exports = {
  settings: {
    // multiple resolvers
    'import-x/resolver-next': [
      customResolverObject,
      createTsResolver(enhancedResolverOptions),
      createOxcResolver(oxcOptions),
    ],
    // single resolver:
    'import-x/resolver-next': [createOxcResolver(oxcOptions)]
  }
}

The new import-x/resolver-next no longer accepts strings as the resolver, thus will not be compatible with the ESLint legacy config (a.k.a. .eslintrc). Those who are still using the ESLint legacy config should stick with import-x/resolver.

In the next major version of eslint-plugin-import-x (v5), we will rename the currently existing import-x/resolver to import-x/resolver-legacy (which allows the existing ESLint legacy config users to use their existing resolver settings), and import-x/resolver-next will become the new import-x/resolver. When ESLint v9 (the last ESLint version with ESLint legacy config support) reaches EOL in the future, we will remove import-x/resolver-legacy.

We have also made a few breaking changes to the new resolver API design, so you can't use existing custom resolvers directly with import-x/resolver-next:

// When migrating to `import-x/resolver-next`, you CAN'T use legacy versions of resolvers directly:
module.exports = {
  settings: {
    // THIS WON'T WORK, the resolver interface required for `import-x/resolver-next` is different.
    'import-x/resolver-next': [
       require('eslint-import-resolver-node'),
       require('eslint-import-resolver-webpack'),
       require('some-custom-resolver')
    ];
  }
}

For easier migration, the PR also introduces a compat utility importXResolverCompat that you can use in your eslint.config.js:

// eslint.config.js
import eslintPluginImportX, { importXResolverCompat } from 'eslint-plugin-import-x';
// or
const eslintPluginImportX = require('eslint-plugin-import-x');
const { importXResolverCompat } = eslintPluginImportX;

module.exports = {
  settings: {
    // THIS WILL WORK as you have wrapped the previous version of resolvers with the `importXResolverCompat`
    'import-x/resolver-next': [
       importXResolverCompat(require('eslint-import-resolver-node'), nodeResolveOptions),
       importXResolverCompat(require('eslint-import-resolver-webpack'), webpackResolveOptions),
       importXResolverCompat(require('some-custom-resolver'), { option1: true, option2: '' })
    ];
  }
}
For custom import resolver developers

This is the new API design of the resolver interface:

export interface NewResolver {
  interfaceVersion: 3;
  name?: string; // This will be included in the debug log
  resolve: (modulePath: string, sourceFile: string) => ResolvedResult;
}

// The `ResultNotFound` (returned when not resolved) is the same, no changes
export interface ResultNotFound {
  found: false;
  path?: undefined;
}

// The `ResultFound` (returned resolve result) is also the same, no changes
export interface ResultFound {
  found: true;
  path: string | null;
}

export type ResolvedResult = ResultNotFound | ResultFound;

You will be able to import NewResolver from eslint-plugin-import-x/types.

The most notable change is that eslint-plugin-import-x no longer passes the third argument (options) to the resolve function.

We encourage custom resolvers' authors to consume the options outside the actual resolve function implementation. You can export a factory function to accept the options, this factory function will then be called inside the eslint.config.js to get the actual resolver:

// custom-resolver.js
exports.createCustomResolver = (options) => {
  // The options are consumed outside the `resolve` function.
  const resolverInstance = new ResolverFactory(options);

  return {
    name: 'custom-resolver',
    interfaceVersion: 3,
    resolve(mod, source) {
      const found = resolverInstance.resolve(mod, {});

      // Of course, you still have access to the `options` variable here inside
      // the `resolve` function. That's the power of JavaScript Closures~
    }
  }
};

// eslint.config.js
const { createCustomResolver } = require('custom-resolver')

module.exports = {
  settings: {
    'import-x/resolver-next': [
       createCustomResolver(options)
    ];
  }
}

This allows you to create a reusable resolver instance to improve the performance. With the existing version of the resolver interface, because the options are passed to the resolver function, you will have to create a resolver instance every time the resolve function is called:

module.exports = {
  interfaceVersion: 2,
  resolve(mod, source) {
    // every time the `resolve` function is called, a new instance is created
    // This is very slow
    const resolverInstance = ResolverFactory.createResolver({});
    const found = resolverInstance.resolve(mod, {});
  },
};

With the factory function pattern, you can create a resolver instance beforehand:

exports.createCustomResolver = (options) => {
  // `enhance-resolve` allows you to create a reusable instance:
  const resolverInstance = ResolverFactory.createResolver({});
  const resolverInstance = enhanceResolve.create({});

  // `oxc-resolver` also allows you to create a reusable instance:
  const resolverInstance = new ResolverFactory({});

  return {
    name: "custom-resolver",
    interfaceVersion: 3,
    resolve(mod, source) {
      // the same re-usable instance is shared across `resolve` invocations.
      // more performant
      const found = resolverInstance.resolve(mod, {});
    },
  };
};
Patch Changes
gajus/eslint-plugin-jsdoc (eslint-plugin-jsdoc)

v50.6.1

Compare Source

Bug Fixes

v50.6.0

Compare Source

Features
  • lines-before-block: move start-of-block checking behind off-by-default checkBlockStarts option (#​1341) (f9b102d)
eslint-community/eslint-plugin-n (eslint-plugin-n)

v17.15.0

Compare Source

🌟 Features
🩹 Fixes
  • no-unsupported: Correctly handle recursive objects on a per module basis (#​396) (db384d1)
eslint-community/eslint-plugin-promise (eslint-plugin-promise)

v7.2.1

Compare Source

🩹 Fixes
  • no-callback-in-promise: false triggering of callback (#​574) (8324564)
🧹 Chores

v7.2.0

Compare Source

🌟 Features
🩹 Fixes
  • permit appropriate computed member expressions and prototype access (#​535) (4de9d43)
🧹 Chores
testing-library/eslint-plugin-testing-library (eslint-plugin-testing-library)

v7.1.1

Compare Source

Bug Fixes
  • use valid config type for supporting both ESLint v8 and v9 (#​976) (d8e44b2)

v7.1.0

Compare Source

Features
prettier/prettier (prettier)

v3.4.2

Compare Source

diff

Treat U+30A0 & U+30FB in Katakana Block as CJK (#​16796 by @​tats-u)

Prettier doesn't treat U+30A0 & U+30FB as Japanese. U+30FB is commonly used in Japanese to represent the delimitation of first and last names of non-Japanese people or “and”. The following “C言語・C++・Go・Rust” means “C language & C++ & Go & Rust” in Japanese.

<!-- Input (--prose-wrap=never) -->

C言
語
・
C++
・
Go
・
Rust

<!-- Prettier 3.4.1 -->
C言語・ C++ ・ Go ・ Rust

<!-- Prettier 3.4.2 -->
C言語・C++・Go・Rust

U+30A0 can be used as the replacement of the - in non-Japanese names (e.g. “Saint-Saëns” (Charles Camille Saint-Saëns) can be represented as “サン゠サーンス” in Japanese), but substituted by ASCII hyphen (U+002D) or U+FF1D (full width hyphen) in many cases (e.g. “サン=サーンス” or “サン＝サーンス”).

Fix comments print on class methods with decorators (#​16891 by @​fisker)
// Input
class A {
  @&#8203;decorator
  /** 
   * The method description
   *
  */
  async method(foo: Foo, bar: Bar) {
    console.log(foo);
  }
}

// Prettier 3.4.1
class A {
  @&#8203;decorator
  async /**
   * The method description
   *
   */
  method(foo: Foo, bar: Bar) {
    console.log(foo);
  }
}

// Prettier 3.4.2
class A {
  @&#8203;decorator
  /**
   * The method description
   *
   */
  async method(foo: Foo, bar: Bar) {
    console.log(foo);
  }
}
Fix non-idempotent formatting (#​16899 by @​seiyab)

This bug fix is not language-specific. You may see similar change in any languages. This fixes regression in 3.4.0 so change caused by it should yield same formatting as 3.3.3.

// Input
<div>
  foo
  <span>longlonglonglonglonglonglonglonglonglonglonglonglonglonglongl foo</span>
  , abc
</div>;

// Prettier 3.4.1 (first)
<div>
  foo
  <span>
    longlonglonglonglonglonglonglonglonglonglonglonglonglonglongl foo
  </span>, abc
</div>;

// Prettier 3.4.1 (second)
<div>
  foo
  <span>longlonglonglonglonglonglonglonglonglonglonglonglonglonglongl foo</span>
  , abc
</div>;

// Prettier 3.4.2
<div>
  foo
  <span>longlonglonglonglonglonglonglonglonglonglonglonglonglonglongl foo</span>
  , abc
</div>;

v3.4.1

Compare Source

diff

Remove unnecessary parentheses around assignment in v-on (#​16887 by @​fisker)
<!-- Input -->
<template>
  <button @&#8203;click="foo += 2">Click</button>
</template>

<!-- Prettier 3.4.0 -->
<template>
  <button @&#8203;click="(foo += 2)">Click</button>
</template>

<!-- Prettier 3.4.1 -->
<template>
  <button @&#8203;click="foo += 2">Click</button>
</template>

v3.4.0

Compare Source

diff

🔗 Release Notes

Configuration

📅 Schedule: Branch creation - "* 0-3 * * 1" in timezone Asia/Tokyo, Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot added the renovate label Dec 1, 2024
@renovate renovate bot enabled auto-merge (squash) December 1, 2024 15:08
@renovate renovate bot force-pushed the renovate/linters branch 3 times, most recently from 3a1a11f to f2ff5b4 Compare December 3, 2024 14:00
@renovate renovate bot changed the title fix(deps): replace linters fix(deps): update linters Dec 3, 2024
@renovate renovate bot force-pushed the renovate/linters branch 3 times, most recently from eccea97 to 26a1823 Compare December 8, 2024 19:59
@renovate renovate bot force-pushed the renovate/linters branch from 26a1823 to 426fee7 Compare December 10, 2024 03:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
renovate
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0 participants