Martin Štekl stekycz Prague, Czech Republic

nette-intellij/intellij-neon 93

Neon language support for PhpStorm / IntelliJ IDEA

stekycz/Cronner 75

Simple tool which helps with maintenance of cron tasks.

stekycz/graphql-extra-scalars 7

A collection of custom GraphQL types like Email, URL and password.

stekycz/Collections 5

[ABADONED] Basic collections for PHP using arrays

stekycz/authentication-checklist 4

Help for projects and apps with product decisions related to authentication

stekycz/cucumber-4-api-blueprint 3

[ABADONED] Cucumber predefined step definitions for RESTful API testing using API Blueprint by Apiary

stekycz/gallery-nette-plugin 3

[ABADONED] This plugin helps to create galleries of photos.

stekycz/cronner-demo 1

Demo application using Cronner extension for Nette Framework

stekycz/dash-nette 1

[ABADONED] Generates a Dash docset for Nette Framework

stekycz/application 0

Nette Application component

issue commenttypescript-eslint/typescript-eslint

[prefer-readonly-parameter-types] Support all readonly built-in types

Thank you for such a response! I can definitely prepare a PR for treatReadonlyBuiltinsAsSafe: boolean.

The second option (treatMethodsAsReadonly: boolean) could be treated in 2 possible way I can imagine:

  1. Differentiate methods and properties (even the property type is a function type).
  2. Differentiate methods and function typed properties from other properties.

I believe the first is the correct one, however, it might be harder to implement as you suggest.

However, do you want to support both options? And do you want to allow them combining or should the options schema require them exclusively? I would expect that using both, either or none should be possible.


comment created time in 2 months

issue commentDefinitelyTyped/DefinitelyTyped

[@types/luxon] - all types as read-only

I am not linting my dependencies. I am linting my code and when I want to have an argument to some function to be type DateTime for example then the type is validated to be read-only. The only way I can make it work is by using Readonly<...> or DeepReadonly<...> everywhere which makes the code less readable.

However, I still believe it should be read-only anyway. The usage with the ESlint rule is only the reason I found the issue 😉


comment created time in 2 months

issue commenttypescript-eslint/typescript-eslint

[prefer-readonly-parameter-types] Support all readonly built-in types

I understand 🤔 probably...

So the array methods might be reassigned as well but it needs extra handling because there is no other way?

I am thinking about how to make the option work. I have also created a partially related issue for luxon's type definitions. I see 3 possible solutions right now:

  1. List of types that are considered read-only (e.g. ReadonlySet, ReadonlyMap). However, that is not usable with luxon without the issue above fixed.
  2. Special flag to consider implemented list of types as read-only not allowing custom types in the list.
  3. Flag to consider all object methods read-only. However, that would weaken the rule which might introduce some bugs (that would be hard to trace).

There is always a way to use Readonly<...> everywhere. However, that makes the code less readable IMO. For some type definitions DeepReadonly<...> might be used, however, it makes the readability worse adding an extra dependency (that might be useful anyway).

I believe that using Readonly<...> (or DeepReadonly<...> respectively) is the only correct way. From the options above, I think that the third option might be implemented because it makes sense in the context of generic usage even it might not be as safe as possible.

What is your opinion?


comment created time in 2 months

issue openedDefinitelyTyped/DefinitelyTyped

[@types/luxon] - all types as read-only

  • [x] I tried using the @types/luxon package and had problems.
  • [x] I tried using the latest stable version of tsc.
  • [x] I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).
  • [x] Mention the authors (see Definitions by: in index.d.ts) so they can respond.
    • Authors: @colbydehart @FourwingsY @jsiebern @mastermatt @pietrovismara @dawnmist @ycmjason @mdanka

I want to use prefer-readonly-parameter-types ESlint rule for TypeScript, however, all usage of DateTime or Interval from luxon are not considered read-only.

I see that all properties are not marked read-only in the definition. I would expect them to be read-only because the library itself is immutable so having mutable fields does not make any sense.

I would add the flag to all value object types/classes to be usable with the rule. I am not sure about changing type definitions for options and parameters. However, I expect the library uses them immutably as well.

I am also aware it would be a BC breaking change. On the other hand, it should provide better type checking closer to what luxon probably wants.

created time in 2 months

issue openedtypescript-eslint/typescript-eslint

[prefer-readonly-parameter-types] Support all readonly built-in types

I would expect the rule to accept all built-in types that are considered read-only. The rules check objects, arrays, and tuples. However, it considers ReadonlySet and ReadonlyMap as objects resulting in false positive.


  "rules": {
    "@typescript-eslint/prefer-readonly-parameter-types": ["error", {
      "checkParameterProperties": true
const x = (data: ReadonlySet<string>): void => {};
const y = (data: ReadonlyMap<string, string>): void => {};

Expected Result

Pass linting because the types used are read-only.

Actual Result

Fails because the type itself has a few methods that are not defined read-only (because they are methods, not properties with function values).


package version
@typescript-eslint/eslint-plugin 2.24.0
@typescript-eslint/parser 2.24.0
TypeScript 3.8.3
ESLint 6.8.0
node 12.15.0
yarn 1.22.4

created time in 2 months