Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

static class properties invalid #6997

Closed
egamma opened this issue Feb 10, 2016 · 32 comments
Closed

static class properties invalid #6997

egamma opened this issue Feb 10, 2016 · 32 comments
Labels
Bug A bug in TypeScript Fixed A PR has been merged for this issue

Comments

@egamma
Copy link
Member

egamma commented Feb 10, 2016

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

@egamma egamma self-assigned this Feb 10, 2016
@egamma
Copy link
Member Author

egamma commented Feb 10, 2016

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 :)

@egamma
Copy link
Member Author

egamma commented Feb 10, 2016

Nette Grüsse nach Wollishofen :)
Danke 😄

The warning comes from Salsa - moving.

@mhegazy mhegazy assigned billti and unassigned egamma Feb 10, 2016
@mhegazy mhegazy added Bug A bug in TypeScript Salsa labels Feb 10, 2016
@mhegazy mhegazy added this to the TypeScript 1.8.2 milestone Feb 10, 2016
@dvdzkwsk
Copy link

@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,
};

@egamma
Copy link
Member Author

egamma commented Feb 15, 2016

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.

@dvdzkwsk
Copy link

Thanks for the clarification!

@RyanCavanaugh
Copy link
Member

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?

@JeandeCampredon
Copy link

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

@jwulf
Copy link

jwulf commented Feb 20, 2016

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

@sethreidnz
Copy link

@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?

@billti
Copy link
Member

billti commented Feb 24, 2016

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..).

@mhegazy
Copy link
Contributor

mhegazy commented Feb 24, 2016

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.

@egamma
Copy link
Member Author

egamma commented Feb 25, 2016

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

@lgra
Copy link

lgra commented Mar 9, 2016

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

@kinolaev
Copy link

kinolaev commented Mar 9, 2016

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

@janmarek
Copy link

janmarek commented Mar 9, 2016

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

@lgra
Copy link

lgra commented Mar 9, 2016

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.

@robcaldecott
Copy link

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.

@egamma
Copy link
Member Author

egamma commented Mar 11, 2016

@robcaldecott pls see this comment microsoft/vscode#3804 (comment). This will be in the march update.

@egamma
Copy link
Member Author

egamma commented Mar 26, 2016

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

@dvdzkwsk
Copy link

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

@Charmatzis
Copy link

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.

@Charmatzis
Copy link

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

@mhegazy
Copy link
Contributor

mhegazy commented May 18, 2016

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.

@egamma
Copy link
Member Author

egamma commented May 19, 2016

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

@bartosz-k
Copy link

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.

@guido4000
Copy link

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

@egamma
Copy link
Member Author

egamma commented Sep 12, 2016

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

@shawnlauzon
Copy link

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

@mhegazy
Copy link
Contributor

mhegazy commented Nov 13, 2016

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

@shawnlauzon
Copy link

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.

@mhegazy
Copy link
Contributor

mhegazy commented Nov 13, 2016

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.

@christopheranderson
Copy link

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.

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Bug A bug in TypeScript Fixed A PR has been merged for this issue
Projects
None yet
Development

No branches or pull requests