0.10.10 erroring on object spread properties in .js files

[garthk]

… and I can't turn it off by setting javascript.validate.enable false.

Perhaps this is a soft documentation bug: the release notes proudly mention experimentalObjectRestSpread but then say:

Support for ObjectRestSpread is not yet provided by Salsa but it is on the roadmap (see microsoft/TypeScript#2103).

… which is confusing and misleading.

It's confusing because the stand-out tone of core dev responses to that issue is "not until TC39 moves it to stage 3; bother them, not us", which is much less optimistic than the Feb 2016 release notes or the TypeScript Roadmap itself.

It's misleading because it fails to describe the impact of "support… not yet provided" as error messages you can't make go away. If there's some way to make them go away, please describe it in that part of the release notes. If not, I don't think it's too strong to outright advise users of object spread properties to delay upgrading.

Without a work-around, this kills code for me, as I now have to dig for the real errors amongst a few dozen erroneous:

• Property assignment expected.
• Argument expression expected.
• Declaration or statement expected.

I trust a workaround is possible, as code is not erroring in JSX.

[kumarharsh]

+1

[dlong500]

I'm happy for the inclusion of the Typescript-based Salsa syntax support, but as @garthk mentions it is an odd situation that we are now in. ESLint is also very much encouraged in the vscode docs (and I've been using it for quite some time already).

What I don't understand is why we can't have Salsa-based syntax color support (and maybe some other things as well) without forcing the Salsa (Typescript) syntax validation. It seems to me that if ESLint is to become the standard (or at least recommended) way for validation then there should be a simple way to disable the Salsa/Typescript validation. Apparently at the moment there is not, and this is a very serious impediment to productivity.

The issues with incomplete syntax color coding in past versions is highly preferable to an inability to disable code validation that isn't up to par with current coding conventions. The musings about specs and javascript stages on the Typescript repo in regards to the object spread operator don't justify a continued lack of support for a feature that is well-established in practice and is supported in Babel. That's fine if the Typescript devs want to hold back, but now Microsoft is forcing the Typescript opinions on everyone using vscode without an ability to disable it. I guess I just don't understand why the original javascript.validate.enable option can't be used to disable Typescript validation as well. After all, if we're using ESLint why do we need another validator?

There really doesn't seem to be a whole lot of noise about it yet, but that's probably because the February release only just came out. Salsa support in the January release was opt-in, and given the hoops you had to jump through to enable it I'm thinking that not a whole lot of people tried it out.

If I'm missing something then please enlighten me, but I haven't found any workaround yet (not even in the vscode alpha release).

Sorry if it seems like I'm cranky. I also just spent several hours figuring out that ESLint 2.3.0 breaks all linting in vscode at the moment.

[josebalius]

I feel the same way :/ I was looking forward to the Feb release to maybe switch from Atom but this is a blocker for me.

[egamma]

@garthk I will change the doc to make this limitation more obvious.

[egamma]

We will revive the javascript.validate.enable setting #3909.

This will remove the red squiggles, but this will not fix that Salsa doesn't understand these syntactic constructs. This means the code understanding experience is limited, e.g, when it comes to intellisense, go to definition.

@dlong500 @garthk from this feedback I conclude that these limitations are tolerable as long as the red squiggles do not get in your way. Is this correct?

[kumarharsh]

these limitations are tolerable as long as the red squiggles do not get in your way. Is this correct?

Yes, you can say that. That's one major irritant because it's expected that linting run smoothly when transitioning from other editors. Linting and intellisense are separate things (from the user's perspective), and I think it's a more logical tradeoff that we'd lose intellisense support until Salsa comes up to speed.

[egamma]

@kumarharsh this explanation makes sense, thanks.

[josebalius]

@egamma reviving that setting would be great. I think it allows me to fully switch to vscode :)

[dlong500]

How is the intellisense and syntactic recognition of Salsa different from the pre-Salsa engine? If there isn't much difference then I'm fine with simply disabling Salsa's validation. However, if there is a big difference would it be possible to have an option to continue to use the pre-Salsa engine for intellisense at least until Salsa matures a bit?

[garthk]

@egamma removing the red squiggles and entries in showErrorsWarnings (⌘⇧M) will help a great deal, catching code back up to subl in workability.

FWIW, goToDeclaration and triggerSuggest are still limping along. Nice work, that.

[egamma]

@dlong500 both Salsa and the previous JS infrastructure build on the TypeScript parser and AST. The previous JS infrastructure has the same limitations when it comes to using ES7 language features, but it supported to turn off validation.

One issue is that the TypeScript version used for the previous JS infrastructure is now really out of date. This is why we need to deprecate it as soon as possible.

until Salsa matures a bit?
Do you have particular concerns with regard to the Salsa maturity.

[egamma]

@garthk the plan is to bring back the option and it will be in next update in the insiders channel, which we plan to make next week.