conjure-typescript
conjure-typescript copied to clipboard
Provide option to emit interface names without "I" prefix
The convention of naming interfaces starting with I
, e.g. ILogger
, is an unpopular one in the TypeScript community. Some arguments against it are as follows:
-
This convention clashes with the TypeScript standard library (
lib.dom.d.ts
, etc.) and with all of DefinitelyTyped. -
Whether an identifier is a type or a variable is always evident from its position in the grammar, except in
import
/export
statements where it doesn't matter, meaning theI
adds line noise without communicating anything.- The argument that it helps in import statements to avoid importing values when only types are desired is a weak one in the context of Conjure in particular, as Conjure currently generates union types with
I
-prefixed names which are also values (objects which contain helper functions like.visit()
). There is no reason to think this is not done by other projects as well.
- The argument that it helps in import statements to avoid importing values when only types are desired is a weak one in the context of Conjure in particular, as Conjure currently generates union types with
-
In cases where it is desirable to define an interface and a default class which implements that interface, the interface type should be referenced often while the concrete type is referenced rarely. Thus, naming ugliness should be placed in the concrete type rather than the interface (e.g.
Foo
/DefaultFoo
, notIFoo
/Foo
). -
The prefixing is inconsistent in that it is only sometimes used for types defined with
type
rather thaninterface
. For example, Conjure union type names are prefixed, but presumably type aliases would not be. -
Microsoft's own internal guidelines say not to do so. While this is of course for their own repo, as the maintainers of TypeScript their style guidelines have some weight in the community.
For these reasons, we should provide an option to leave out the prefix, as this would be desirable for the majority of potential third-party consumers.
Presumably we'd also want to phase out usage of the tslint rule at the same time? https://palantir.github.io/tslint/rules/interface-name/
I would be very much in favor of that, but I consider that less important because it can be disabled in config (which almost everyone does).
There's a long-standing issue on TSLint to remove interface-name
as a default rule: https://github.com/palantir/tslint/issues/1520.