Typescript-react-starter: Build error following README tutorial

Created on 14 Apr 2018  ·  10Comments  ·  Source: microsoft/TypeScript-React-Starter

It appears that the requirements for interface names has changed since the README steps were written. It now fails to run if an interface name doesn't begin with an I.

Steps

  1. Follow along with the README through to creating a new component.
  2. Run the project with npm run start.

Expected

App should run with new Hello component rendered.

Actual

App fails to compile with the following error in the browser.

Failed to compile
…/my-app/src/components/Hello.tsx
(3,18): interface name must start with a capitalized I
This error occurred during the build time and cannot be dismissed.

Workaround

I haven't used enough TypeScript to know if this is an appropriate workaround, but renaming the Props interface to IProps (and its usage) will resolve this issue. I suppose there could be a setting somewhere that can be changed to start ignoring this error instead, but I'm just getting started with this tutorial.

export interface IProps { … }

…

function Hello({ name, enthusiasmLevel = 1 }: IProps) { … }

Additionally, this also affects the class-based variant of the Hello component as well as later examples working on this component.

Most helpful comment

Ran into this as well. The tslint rule that is causing this is https://palantir.github.io/tslint/rules/interface-name/.
You can add a rule to tslint.json that disables linting interface names. Here's the contents of my working tstlint.json file:

{
  "extends": ["tslint:recommended", "tslint-react", "tslint-config-prettier"],
  "linterOptions": {
    "exclude": [
      "config/**/*.js",
      "node_modules/**/*.ts"
    ]
  },
  "rules": {
     "interface-name":[false]   
  }
}

All 10 comments

Judging from this response to the PR I submitted, the workaround may not be valid. Is there some way to tell TypeScript to allow non-I interfaces so these instructions work again?

This is because of tslint, not the ts-compiler. In general any tslint error such as styling issues prevent running the program. I posted a similar issue for this, but there hasn't been a reply yet. A workaround is to remove all content from tslint.json, meaning no rules are then enforced for tslint.

That's good to know. It seems like there must be a disconnect between the default tslint settings and the TypeScript contribution guidelines. I've bailed on picking up TypeScript, but there is probably a single tslint rule that could be altered rather than the entire linting process.

In the case of this tutorial, either set of steps should probably be added to help new users.

Same thing is happening to me right now. @kaba2 I deleted everything on the tslint.json and nothing improved. I'm still getting the same error.

@dieferrari Probably a matter of restarting "npm start", if tslint reads its config once when started?

@kaba2 I tried that but it didn't worked, actually it didn't compiled.

So, a barrier to entry here...

I did the same, found this issue, now 🤷‍♀️

Ran into this as well. The tslint rule that is causing this is https://palantir.github.io/tslint/rules/interface-name/.
You can add a rule to tslint.json that disables linting interface names. Here's the contents of my working tstlint.json file:

{
  "extends": ["tslint:recommended", "tslint-react", "tslint-config-prettier"],
  "linterOptions": {
    "exclude": [
      "config/**/*.js",
      "node_modules/**/*.ts"
    ]
  },
  "rules": {
     "interface-name":[false]   
  }
}

@linelson very good. Not sure why tslint is so strict. It's a bit of a hinderance. Who cares if the interface doesn't start with 'I' Also there's no need for brackets around false This will suffice:

"rules": { "interface-name": false }

Something else that will help catch TS lint issues is:

yarn global add tslint

Then:

tslint --fix <path to your ts or tsx file>

Not sure why tslint is so strict. It's a bit of a hinderance. Who cares if the interface doesn't start with 'I'.

Well, the idea of the rule is good (see Rationale): _Makes it easy to differentiate interfaces from regular classes at a glance._

Perhaps it's not such a big issue with Props, but it can save a bit of mental processing time elsewhere.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

StokeMasterJack picture StokeMasterJack  ·  4Comments

BenjaminWatts picture BenjaminWatts  ·  6Comments

painreign picture painreign  ·  6Comments

ghost picture ghost  ·  7Comments

samblake picture samblake  ·  5Comments