Typescript: static class properties invalid

Created on 10 Feb 2016  路  32Comments  路  Source: microsoft/TypeScript

_From @nwehrle on February 9, 2016 21:17_

I use eslint to lint my jsx files. Before I switched to salsa, the linting inside the editor worked fine. After switching to salsa the linting fails inside the editor.
bildschirmfoto 2016-02-09 um 22 00 18

Salsa is enabled:
bildschirmfoto 2016-02-09 um 22 13 44

Linting from the shell still works without any errors or warnings.
I expect vscode to not show any linting errors.

System:
OSX 10.11.2
vscode 0.10.8
db71ac615ddf9f33b133ff2536f5d33a77d4774e

jsconfig.json:

{
  "compilerOptions": {
    "target": "ES6",
    "module": "system",
    "experimentalDecorators": true
  },

  "exclude": [
    "node_modules"
  ]
}

User settings:

{
  "javascript.validate.enable": false,
  "editor.tabSize": 2,
  "files.trimTrailingWhitespace": true,
  // Migrated from previous "File | Auto Save" setting:
  "files.autoSave": "onFocusChange"
}

Partial eslintrc:

 "rules": {
    "func-names": 0,
    "no-unused-expressions": 0,
    "id-length": 0,
    "no-multi-spaces": 0,
    "no-mixed-spaces-and-tabs": 2,

    "no-unused-vars": [1, {"vars": "all", "args": "none"}],
    "react/jsx-uses-react": 1,
    "react/prop-types": 0,
    "no-console": 0
  },
  "plugins": [
    "react"
  ]

_Copied from original issue: Microsoft/vscode#2866_

Bug Fixed

Most helpful comment

Seems like we should allow any syntax that the TypeScript parser is capable of recognizing and is part of a JavaScript standards proposal (regardless of _stage_), and leave it up to the user to figure out if their target engine is capable of supporting it (just as they have to for classes, arrow functions, etc..).

All 32 comments

_From @nwehrle on February 10, 2016 9:55_

The lint error message is:
'property declarations' can only be used in a .ts file.
(property) SearchProfileList.propTypes: {
list: any;
getSearchProfileList: any;
deleteSearchProfile: any;
editSearchProfile: any;
location: any;

Nette Gr眉sse nach Wollishofen :)

Nette Gr眉sse nach Wollishofen :)
Danke :smile:

The warning comes from Salsa - moving.

@Same thing here, looking at the default settings in VSCode it appears:

"javascript.validate.enable"

is no longer a setting? I realize this issue has been moved to TypeScript, but it doesn't seem like you can disable validation for JS in VSCode anymore?

Also, note that the same error occurs when using Type aliases (such as with Flow):

type aliases can only be used in a .ts file

type Action = {
  type: string,
  payload: Object,
  error?: Object,
};

looking at the default settings in VSCode it appears:
"javascript.validate.enable"
is no longer a setting?

correct, javascript.validate.enable does not apply to Salsa anymore. The existing JS language service supported additional warnings that are currently not supported by Salsa and this is why we recommend to use a linter like eslint or jshint.

Thanks for the clarification!

This code isn't valid JavaScript, nor does Babel understand this syntax. It seems like this is a correct error to issue. How is this being transpiled?

This code is usable with the stage-0 preset of babel.

Yes, I also use this. ES7 static class properties + ES7 class property initialisation.

With typescript-1.9.0-dev.20160220:

I get an error message (property declarations can only be used in a .ts file):

screen shot 2016-02-20 at 10 03 03 pm

But the error goes away if I add a decorator to the class:

screen shot 2016-02-20 at 10 03 57 pm

@jwulf Not knowing enough about experimental specs I'm assuming the decorators are safe to use even though you get a different error about using experimental decorators?

Seems like we should allow any syntax that the TypeScript parser is capable of recognizing and is part of a JavaScript standards proposal (regardless of _stage_), and leave it up to the user to figure out if their target engine is capable of supporting it (just as they have to for classes, arrow functions, etc..).

In addition to @billti's suggestion, We could add a new flag sourceJSVersion (or some better name) and if specified to es5, then using later features is an errors.

:+1: on both. Adding a 'sourceJSVersion' would bring back a feature the old Code JS language service supported by overloading the target property.

Hi!
In the meantime, is there any workaround in February release ?
A way to disable salsa Javascript validation for example ?

Hello!
As workaround you can enable experimentalDecorators and add @(a=>a)class A{} somewhere in file with properties declaration.

Writing code which does not make sense is not a good workaround for bad syntax highlighting in text editor ;)

Thanks.
I've added a jsconfig.json file at root directory containing:

{
  "compilerOptions": {
    "experimentalDecorators": true,
    "target": "ES6",
    "module": "sommons"

  },
  "exclude": [
    "node_module"
  ]
}

It seems it had remove salsa validation, while eslint is still enabled. Just perfect for my use case.

I cannot use the decorator trick as babel won't compile it (and installing extra babel plugins to workaround this seems excessive). Similarly the "sommons" trick doesn't work either. Does anyone have any other ideas? Right now it looks like a downgrade to an earlier release of VS Code is my only option.

@robcaldecott pls see this comment https://github.com/Microsoft/vscode/issues/3804#issuecomment-194250393. This will be in the march update.

@robcaldecott @davezuko "javascript.validate.enable" is now available again in the version available on the insiders channel (release notes)

Thanks @egamma, I've been on insiders for a week or so now and it's working well.

I written

{
    // See https://go.microsoft.com/fwlink/?LinkId=759670
    // for the documentation about the jsconfig.json format
    "compilerOptions": {
        "target": "es6",
        "module": "es6",
        "experimentalDecorators": true
    },
    "exclude": [
        "node_modules",
        "bower_components",
        "jspm_packages",
        "tmp",
        "temp"
    ]
}

in the jsconfig.json file and now it OK.

I have updated a plugin yesterday and today it shows again the error.... what can I say????

I have updated a plugin yesterday and today it shows again the error.... what can I say????

the issue has not been fixed, and is still open. hopefully we will get to it soon. sorry for the trouble.

@Charmatzis until this issue has been addressed you can disable the syntax errors, pls see the following doc

I like Facebook Flow approach on this. The compiler says that some syntax is experimental, but in order to suppress this message add some config to the .flowconfig. tsc parser recognizes the syntax, but the behaviour is hardcoded. Bad.

Should this be working in V 1.5.1? It does not seem so.

This got fixed in TS 2.0. VS Code 1.5.1 ships with TS 1.8.1. To use TS 2.0 pls see https://code.visualstudio.com/docs/languages/typescript#_using-newer-typescript-versions

I'm having the same issue as #9121, which is supposedly a dupe of this one. This is happening with all the .js files which use Typescript:

capture d ecran 2016-11-12 a 14 01 31
and:
capture d ecran 2016-11-12 a 14 06 56

However I'm currently using TS 2.2.0 in which this should currently be fixed. Changing from Javascript to Typescript to Typescript React seems to force a recheck but with the same result.
capture d ecran 2016-11-12 a 14 02 21

VSCode 1.7.1
macOS 10.12.1

Why not name the file into .ts file? type aliases is not valid JS anyways.

I don't own the package; this is the sample code generated by Ignite for Reactive Native. So I could change it on my local system, but that seems like a poor workaround for something which should work.

I am not sure what is the expectation. this is not JS file. JS has no definition for type aliases declarations in the current version of the spec (ES 2016) or any future one. even if we do allow the TS declarations to be allowed, i do not think it would work for flow-specific syntax. Using file extensions like JS for non-standard features is to blame here.

I think the problem here is that many React templates are using Flow syntax here and there. Many of the default bootstrap React templates have Flow as a babel preset. This is using Flow Class declarations, which is a proposal for ES, currently in stage 2.

I don't believe the right answer for this is to allow class declarations in .js files, yet, though there is a proposal for it. There is a larger issue, I suppose, of allowing TypeScript/VS Code/Salsa/etc. to play nicely with Flow and all its reliance on babel plugins on regular .js files.

The current fix for this is to install the Flow tooling for VS Code and set a workspace setting for "javascript.validate.enable": false. This addressed my problem.

Was this page helpful?
0 / 5 - 0 ratings