It is not a bad practice, but serverId: number = 10 is redundant, because number type is inferred when a property is assigned. This is what TSLint no-inferrable-types warns about:
Explicit types where they can be easily inferred by the compiler make code more verbose.
Unless there is a chance that serverId property may be initially undefined but be defined later (for instance in constructor function), number can be safely omitted.
This approach works best with noImplicitAny option because this way there are no chances that a type will be omitted by mistake because it wasn't inferred.
As was mentioned above, it's technically redundant and can be considered clutter. Personally I don't care for this opinion and prefer to have both the type and the value for a variety of specific minor workflow reasons and I don't consider it to be the level of clutter warranting a rule. If you want to disable it, here's how.
This might be weird coming for this now, but I was getting the similar error and couldn't find the "no-inferrable-types" attribute in the tslint.json file of my angular app.
I don't know why it didn't generate that in the first place but I had to insert it here
P.S. This is for someone who might be wandering with the same issue as I did, or I might be wrong because no one in any of the solutions mentioned that this has to be added from our end in the json file.