no-unnecessary-type-assertion, no-unnecessary-type-assertion

[jpike88]

Description

https://typescript-eslint.io/rules/no-unnecessary-type-assertion/

[xunilrj]

We don't have type information currently.
Any idea what we could do with the information we have now?

[latin-1]

@xunilrj Sorry for bothering you. Is there a future roadmap for type information? I'd like to know more about how Rome plans to implement type-related rules like typescript-eslint. Thanks

[xunilrj]

Is there a future roadmap for type information?

Yes.

We are currently researching interesting type aware lints and what implementation would they need.
That is why I asked.

The lint examples also looks not realistic to me. Would be interesting to see real use cases of this rule.

[jpike88]

Yeah the examples in the link are poor.

it’s more like:

‘’’
const x: number = 4;
‘’’

This kind of unneeded type declaration adds noise to the code

[xunilrj]

Nice. These I think we can do.
I will put here in my list to research.

[latin-1]

@xunilrj Is there an issue for tracking the type info feature? This is so important to me that I'd like to know when it will be available so that I can move my projects to Rome. Thanks

[xunilrj]

Not yet. I am still researching about type aware lints.
@latin-1 Do you have other lint rules you think are essential?

[latin-1]

@xunilrj
https://typescript-eslint.io/rules/no-floating-promises/
I can’t write async code without it 😝

---

Edited: For a real-world use case:

import fs from "node:fs/promises";
(async () => {
  fs.writeFile(...);
  // ^ oops, I forgot to write `await`

  // do something with that file
})();

[Conaclos]

@xunilrj
I could add the following recommended rule from ESLint TypeScript that require type info:

• await-thenable
• no-floating-promises
• no-for-in-array
• no-misused-promises
• restrict-template-expressions (enabling allowNumber, allowBoolean, allowNullish)
• restrict-plus-operands (same for * + - / %?)
• unbound-method
• require-await

a single promise rule could merge several promise-related rules?

I could merge the following recommended rule into a single rule no-any:

• no-unsafe-arguments
• no-unsafe-assignment
• no-unsafe-call
• no-unsafe-member-access
• no-unsafe-return

I could also add the following strict rules:

• no-base-to-string
• no-meaningless-void-operator
• no-unnecessary-boolean-literal-compare
• no-unnecessary-condition
• no-unnecessary-type-arguments
• prefer-includes
• prefer-nullish-coalescing
• prefer-return-this-type
• prefer-string-starts-ends-with
• no-throw-literal

And the following rules:

• no-confusing-void-expression
• no-redundant-type-constituents
• prefer-readonly
• promise-function-async
• require-array-sort-compare (enabling ignoreStringArrays?)
• strict-boolean-expressions (enabling optional chaining compared to ESLint)
• switch-exhaustiveness-check

Rome could implement a "simple" type system (ignoring advanced type features such as mapped types, conditional types, interface merging).

[Conaclos]

Just for reference: the TS team is discussing which semantic rule is worth the linting time.

[github-actions]

👋 @rome/staff please triage this issue by adding one of the following labels: S-Bug: confirmed, S-Planned , S-Wishlist or umbrella

[jpike88]

just got caught out by something that switch-exhaustiveness-check would have prevented. I think just a simple type checking system capable of unioning literals or something would be plenty... no need to go full on

[gkiely]

One great benefit of no-unsafe-assignment is that it prevents any library types from leaking into your codebase. It's a nice reminder to assert the expected type.

While I can use Rome for linting development builds. Without this rule it is not feasible for me to use it for production builds.