fix: Use updated types from @eslint/core #66

nzakas · 2024-11-21T19:47:07Z

Prerequisites checklist

I have read the contributing guidelines.

What is the purpose of this pull request?

Update the plugin to use the latest types from @eslint/core.

What changes did you make? (Give an overview)

Added types.ts files to define types.
Updated rules to use RuleDefinition type
Updated JSONLanguage to use IJSONLanguage type
Updated JSONSourceCode to use IJSONSourceCode type

Related Issues

Is there anything you'd like reviewers to focus on?

The types test fails with this, and I don't understand why. The project builds just fine. Maybe @fasttime can take a look?

tests/types/types.test.ts

fasttime · 2024-11-22T14:31:42Z

It looks like the type tests are failing because the strict option is not compatible with the @eslint/core types:

json/tests/types/tsconfig.json

Line 6 in a6c0bc9

"strict": true

We could remove that option for the moment since it's only used in the tests. In the long term I think it would be good to make sure that the @eslint/core types are strict compliant, so they can be used by TS projects with that option enabled. As I said in a previous comment, I don't think it's necessary to enable strict mode for the whole rewrite repo.

nzakas · 2024-11-22T15:29:39Z

It looks like the type tests are failing because the strict option is not compatible with the @eslint/core types

Can you explain what the compatibility issue is? And why does running tsc on the project build fine but the type tests fails?

fasttime · 2024-11-22T17:48:54Z

Can you explain what the compatibility issue is?

The issue is in the definition of RuleVisitor in @eslint/core:

export interface RuleVisitor {
	/**
	 * Called for each node in the AST or at specific times during the traversal.
	 */
	[key: string]: (...args: any[]) => void;
}

from https://github.com/eslint/rewrite/blob/3591a7805a060cb130d40d61f200431b782431d8/packages/core/src/types.ts#L102-L107

When the TypeScript strict option is set (or strictNullChecks more specifically) it's no longer possible to assign null or undefined to a property of the RuleVisitorInterface, or to extend it with an optional method (where the value can be a function or undefined).

For example:

let ruleVisitor: RuleVisitor = {};
ruleVisitor.foo = undefined; // Error with strictNullChecks, else OK

interface Bar extends RuleVisitor {
    bar?(): void; // Error with strictNullChecks, else OK
}

The JSONRuleVisitor interface extends RuleVisitor but also defines optional methods, that's why it fails to compile with the strict option.

json/src/types.ts

Lines 58 to 84 in fdde59d

    
           export interface JSONRuleVisitor extends RuleVisitor { 
        
           	Document?(node: DocumentNode): void; 
        
           	Member?(node: MemberNode, parent?: ObjectNode): void; 
        
           	Element?(node: ElementNode, parent?: ArrayNode): void; 
        
           	Object?(node: ObjectNode, parent?: ValueNodeParent): void; 
        
           	Array?(node: ArrayNode, parent?: ValueNodeParent): void; 
        
           	String?(node: StringNode, parent?: ValueNodeParent): void; 
        
           	Null?(node: NullNode, parent?: ValueNodeParent): void; 
        
           	Number?(node: NumberNode, parent?: ValueNodeParent): void; 
        
           	Boolean?(node: BooleanNode, parent?: ValueNodeParent): void; 
        
           	NaN?(node: NaNNode, parent?: ValueNodeParent): void; 
        
           	Infinity?(node: InfinityNode, parent?: ValueNodeParent): void; 
        
           	Identifier?(node: IdentifierNode, parent?: ValueNodeParent): void; 
        
           	"Document:exit"?(node: DocumentNode): void; 
        
           	"Member:exit"?(node: MemberNode, parent?: ObjectNode): void; 
        
           	"Element:exit"?(node: ElementNode, parent?: ArrayNode): void; 
        
           	"Object:exit"?(node: ObjectNode, parent?: ValueNodeParent): void; 
        
           	"Array:exit"?(node: ArrayNode, parent?: ValueNodeParent): void; 
        
           	"String:exit"?(node: StringNode, parent?: ValueNodeParent): void; 
        
           	"Null:exit"?(node: NullNode, parent?: ValueNodeParent): void; 
        
           	"Number:exit"?(node: NumberNode, parent?: ValueNodeParent): void; 
        
           	"Boolean:exit"?(node: BooleanNode, parent?: ValueNodeParent): void; 
        
           	"NaN:exit"?(node: NaNNode, parent?: ValueNodeParent): void; 
        
           	"Infinity:exit"?(node: InfinityNode, parent?: ValueNodeParent): void; 
        
           	"Identifier:exit"?(node: IdentifierNode, parent?: ValueNodeParent): void; 
        
           }

It's possible that there are more incompatibilities in the core types but in this is the only one that's causing troubles with this PR. I tried manually changing the RuleVisitor interface to accept optional methods and then all type tests passed:

export type RuleVisitor = {
    /**
     * Called for each node in the AST or at specific times during the traversal.
     */
-   [key: string]: (...args: any[]) => void;
+   [key in string]?: (...args: any[]) => void;
};

And why does running tsc on the project build fine but the type tests fails?

Because the strict option is only enabled in tests/types/tsconfig.json (the config for type tests), not in the root tsconfig.json which is used for building.

nzakas · 2024-11-22T20:17:49Z

Ah! That is very helpful, thank you.

I think we should change RuleVisitor, then, as I've run into other problems caused by this.

nzakas · 2024-12-04T21:54:55Z

Okay, looks like the RuleVisitor update did the trick. 👍

fasttime

When I build the package everything works well but if I try to import the built package into another TypeScript package with "type": "commonjs", I'm getting errors:

node_modules/@eslint/json/dist/cjs/index.d.cts(12,38): error TS1542: Type import of an ECMAScript module from a CommonJS module must have a 'resolution-mode' attribute.
node_modules/@eslint/json/dist/cjs/index.d.cts(13,40): error TS1542: Type import of an ECMAScript module from a CommonJS module must have a 'resolution-mode' attribute.
node_modules/@eslint/json/dist/cjs/index.d.cts(17,36): error TS1542: Type import of an ECMAScript module from a CommonJS module must have a 'resolution-mode' attribute.
node_modules/@eslint/json/dist/cjs/index.d.cts(18,42): error TS1542: Type import of an ECMAScript module from a CommonJS module must have a 'resolution-mode' attribute.
node_modules/@eslint/json/dist/cjs/index.d.cts(20,52): error TS1542: Type import of an ECMAScript module from a CommonJS module must have a 'resolution-mode' attribute.
node_modules/@eslint/json/dist/cjs/index.d.cts(23,48): error TS1542: Type import of an ECMAScript module from a CommonJS module must have a 'resolution-mode' attribute.
node_modules/@eslint/json/dist/cjs/index.d.cts(25,51): error TS1542: Type import of an ECMAScript module from a CommonJS module must have a 'resolution-mode' attribute.
node_modules/@eslint/json/node_modules/@eslint/plugin-kit/dist/cjs/index.d.cts(12,35): error TS1542: Type import of an ECMAScript module from a CommonJS module must have a 'resolution-mode' attribute.
node_modules/@eslint/json/node_modules/@eslint/plugin-kit/dist/cjs/index.d.cts(13,36): error TS1542: Type import of an ECMAScript module from a CommonJS module must have a 'resolution-mode' attribute.

I think this is because types.ts is considered an ESM module due to the .ts extension, but it's re-exported by dist/cts/index.d.cts which is CommonJS. I'll try to set up a repro.

fasttime · 2024-12-12T14:57:24Z

src/types.ts

+import type {
+	RuleVisitor,
+	TextSourceCode,
+	Language,
+	LanguageOptions,
+	RuleDefinition,
+} from "@eslint/core";


@eslint/core and is imported in the types. Should it be a runtime dependency?

At this point I honestly don't understand when types are supposed to be a dev dependency vs. a runtime dependency. What would you do?

If references to @eslint/core are in the distributed .d.ts files, then I believe @eslint/core will need to be some kind of a runtime dependency. Otherwise end-users might import types from this package and get type errors on @eslint/core not being found.

It does feel weird making a types-only package be a runtime dependency. But 🤷 without first-party support from package managers on delineating "runtime" vs. "types-only" dependencies, it's all "runtime".

tools/dedupe-types.js

Co-authored-by: Francesco Trotta <[email protected]>

nzakas · 2024-12-12T21:59:39Z

I think this is because types.ts is considered an ESM module due to the .ts extension, but it's re-exported by dist/cts/index.d.cts which is CommonJS. I'll try to set up a repro.

That's strange. This is set up the same way I have the packages in the rewrite repo...unless those also have the same problem and we're just not aware.

JoshuaKGoldberg

I'm not confident enough in this repo to explicitly approve or request changes, but left some comments and questions 🙂

JoshuaKGoldberg · 2024-12-13T21:22:26Z

src/types.ts

+	): string;
+}
+
+export type IJSONLanguage = Language<{


[Style] Was the I an intentional addition? It's not typical in TypeScript code.

Suggested change

export type IJSONLanguage = Language<{

export type JSONLanguage = Language<{

Here and with IJSONSourceCode.

Yes, because there's already a class called JSONLanguage, so the type is IJSONLanguage. The I stands for interface.

I have seen this in other projects, and it's fairly typical in languages like Java where you can define an interface separate from a class.

Is there a definitive TypeScript way to handle this? "This" being, there's an interface I want a class to adhere to, and it's only used for that class. What should the name be?

Quick answer: there isn't a single standard, but a name like JSONLanguageLike would be reasonable.

Longer answer: the "interface only used for one class" pattern isn't common in TypeScript-land. If the interface is really only used for that one class then most of the time folks would just use the class name.

Since we're not beholden to classic Java-style class hierarchies, it's less common AFAIU to put everything in a single shape the way the @eslint/core Language type is set up. A lot of architectures avoid classes altogether and instead just go with generic factory functions.

Quickly sketching a theoretical vague equivalent:

declare function createLanguage<Settings extends LanguageSettings> (settings: Settings): Language<Settings>; export const jsonLanguage = createLanguage({ fileType: "text", lineStart: 1, // ... });

In that world, there wouldn't be a need for a JSONLanguage to be explicitly declared. It could be inferred from typeof jsonLanguage with a helper.

Not suggesting changes, just posting context for why this naming problem isn't as commonly solved.

JoshuaKGoldberg · 2024-12-13T21:29:08Z

rollup.config.js

+		copy({
+			targets: [
+				{ src: "src/types.ts", dest: "dist/cjs" },
+				{ src: "src/types.ts", dest: "dist/esm" },


I now see dist/(cjs|esm)/types.d.ts and dst/(cjs|esm)/types.ts files locally. They're identical other than comments and an auto-generated export {}. I don't see anything importing from the types.d.ts. Is the duplication intentional?

FWIW I believe it's more common to have just .d.ts files. My instinct is that the expected path here would be to just have dist/(cjs|esm)/types.d.ts and typedefs use {import("./types.d.ts")}.

Because we run tsc on dist/esm and dist/cjs, types.ts needs to be present in both of those directories in order for the project to compile. types.d.ts is output by tsc from types.ts

Gotcha. I tried renaming src/types.ts to src/types.d.ts with a find-and-replace. I think it's all working here: JoshuaKGoldberg@631810d. At least npm run build passes and the imports all work in editor.

src/rules/no-duplicate-keys.js

JoshuaKGoldberg · 2024-12-13T21:42:37Z

src/types.ts

+import type {
+	RuleVisitor,
+	TextSourceCode,
+	Language,
+	LanguageOptions,
+	RuleDefinition,
+} from "@eslint/core";


If references to @eslint/core are in the distributed .d.ts files, then I believe @eslint/core will need to be some kind of a runtime dependency. Otherwise end-users might import types from this package and get type errors on @eslint/core not being found.

It does feel weird making a types-only package be a runtime dependency. But 🤷 without first-party support from package managers on delineating "runtime" vs. "types-only" dependencies, it's all "runtime".

JoshuaKGoldberg · 2024-12-13T21:45:41Z

src/types.ts

+/**
+ * The `SourceCode` implementation for JSON files.
+ */
+export interface IJSONSourceCode


[Style] Was the I an intentional addition? It's not typical in TypeScript code.

Suggested change

export interface IJSONSourceCode

export interface JSONSourceCode

Here and with IJSONLanguage.

Aside: I've always found this discussion around the choice to not preserve that naming in TypeScript ... interesting: microsoft/TypeScript-Handbook#121

Co-authored-by: Josh Goldberg ✨ <[email protected]>

fasttime · 2024-12-26T07:45:00Z

I think this is because types.ts is considered an ESM module due to the .ts extension, but it's re-exported by dist/cts/index.d.cts which is CommonJS. I'll try to set up a repro.

That's strange. This is set up the same way I have the packages in the rewrite repo...unless those also have the same problem and we're just not aware.

In fact it looks like we have the same problem in the rewrite repo. When I try to use the plugin-kit types in a CommonJS TS file I'm getting an error from the tsc compiler:

node_modules/@eslint/plugin-kit/dist/cjs/index.d.cts:12:35 - error TS1542: Type import of an ECMAScript module from a CommonJS module must have a 'resolution-mode' attribute.

12 export type StringConfig = import("./types.ts").StringConfig;
                                     ~~~~~~~~~~~~

node_modules/@eslint/plugin-kit/dist/cjs/index.d.cts:13:36 - error TS1542: Type import of an ECMAScript module from a CommonJS module must have a 'resolution-mode' attribute.

13 export type BooleanConfig = import("./types.ts").BooleanConfig;
                                      ~~~~~~~~~~~~

Repro

The suggested fix - using a module resolution attribute - works well in current TypeScript v5:

- /** @typedef {import("./types.ts").StringConfig} StringConfig */
- /** @typedef {import("./types.ts").BooleanConfig} BooleanConfig */
+ /** @typedef {import("./types.ts", { with: { "resolution-mode": "import" } }).StringConfig} StringConfig */
+ /** @typedef {import("./types.ts", { with: { "resolution-mode": "import" } }).BooleanConfig} BooleanConfig */

Fix 1

The other option I had in mind was renaming cjs/types.ts to cjs/types.cts and updating the imports accordingly. That works also:

Fix 2

fasttime · 2024-12-27T11:03:49Z

I opened eslint/rewrite#143 to fix the types in plugin-kit.

eslint-github-bot bot added the bug Something isn't working label Nov 21, 2024

nzakas commented Nov 21, 2024

View reviewed changes

tests/types/types.test.ts Show resolved Hide resolved

nzakas mentioned this pull request Nov 22, 2024

Change Request: Update RuleVisitor interface eslint/rewrite#134

Closed

7 tasks

nzakas added 6 commits December 9, 2024 11:04

chore: Update types based on @eslint/core

e7dcc77

feat: Update to new types

6fcc64e

fix: Update types from @eslint/core

cf21288

Update types

6f59ecb

Add types.ts to JSR definition

206a903

Clean up no-unsafe-values.js

5b143e7

nzakas force-pushed the updated-types branch from 0ebe4ee to 5b143e7 Compare December 9, 2024 16:18

Fix tests

2707c14

fasttime reviewed Dec 12, 2024

View reviewed changes

Update tools/dedupe-types.js

aa96174

Co-authored-by: Francesco Trotta <[email protected]>

JoshuaKGoldberg reviewed Dec 13, 2024

View reviewed changes

nzakas and others added 3 commits December 16, 2024 11:13

Update src/rules/no-duplicate-keys.js

6e85c0e

Co-authored-by: Josh Goldberg ✨ <[email protected]>

@eslint/core as runtime dependency

ec0529a

clean up

4659069

fasttime mentioned this pull request Dec 27, 2024

fix: make plugin-kit types usable in CommonJS eslint/rewrite#143

Draft

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: Use updated types from @eslint/core #66

fix: Use updated types from @eslint/core #66

nzakas commented Nov 21, 2024

fasttime commented Nov 22, 2024

nzakas commented Nov 22, 2024

fasttime commented Nov 22, 2024

nzakas commented Nov 22, 2024

nzakas commented Dec 4, 2024

fasttime left a comment •

edited

Loading

fasttime Dec 12, 2024

nzakas Dec 12, 2024

JoshuaKGoldberg Dec 13, 2024

nzakas commented Dec 12, 2024

JoshuaKGoldberg left a comment

JoshuaKGoldberg Dec 13, 2024

nzakas Dec 16, 2024 •

edited

Loading

JoshuaKGoldberg Dec 17, 2024 •

edited

Loading

JoshuaKGoldberg Dec 13, 2024 •

edited

Loading

nzakas Dec 16, 2024 •

edited

Loading

JoshuaKGoldberg Dec 17, 2024

JoshuaKGoldberg Dec 13, 2024

JoshuaKGoldberg Dec 13, 2024

fasttime commented Dec 26, 2024 •

edited

Loading

fasttime commented Dec 27, 2024

	export type IJSONLanguage = Language<{
	export type JSONLanguage = Language<{

	export interface IJSONSourceCode
	export interface JSONSourceCode

fix: Use updated types from @eslint/core #66

Are you sure you want to change the base?

fix: Use updated types from @eslint/core #66

Conversation

nzakas commented Nov 21, 2024

Prerequisites checklist

What is the purpose of this pull request?

What changes did you make? (Give an overview)

Related Issues

Is there anything you'd like reviewers to focus on?

fasttime commented Nov 22, 2024

nzakas commented Nov 22, 2024

fasttime commented Nov 22, 2024

nzakas commented Nov 22, 2024

nzakas commented Dec 4, 2024

fasttime left a comment • edited Loading

Choose a reason for hiding this comment

fasttime Dec 12, 2024

Choose a reason for hiding this comment

nzakas Dec 12, 2024

Choose a reason for hiding this comment

JoshuaKGoldberg Dec 13, 2024

Choose a reason for hiding this comment

nzakas commented Dec 12, 2024

JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

JoshuaKGoldberg Dec 13, 2024

Choose a reason for hiding this comment

nzakas Dec 16, 2024 • edited Loading

Choose a reason for hiding this comment

JoshuaKGoldberg Dec 17, 2024 • edited Loading

Choose a reason for hiding this comment

JoshuaKGoldberg Dec 13, 2024 • edited Loading

Choose a reason for hiding this comment

nzakas Dec 16, 2024 • edited Loading

Choose a reason for hiding this comment

JoshuaKGoldberg Dec 17, 2024

Choose a reason for hiding this comment

JoshuaKGoldberg Dec 13, 2024

Choose a reason for hiding this comment

JoshuaKGoldberg Dec 13, 2024

Choose a reason for hiding this comment

fasttime commented Dec 26, 2024 • edited Loading

fasttime commented Dec 27, 2024

fasttime left a comment •

edited

Loading

nzakas Dec 16, 2024 •

edited

Loading

JoshuaKGoldberg Dec 17, 2024 •

edited

Loading

JoshuaKGoldberg Dec 13, 2024 •

edited

Loading

nzakas Dec 16, 2024 •

edited

Loading

fasttime commented Dec 26, 2024 •

edited

Loading