Che: How to remove annotations and linting?

[shadowcodex]

How do I turn off in editor warnings and errors?

I've got a warning that won't go away and colors half of my screen yellow _sigh_. Cannot find any settings in editor to change this.

Thanks!

[TylerJewell]

@shadowcodex - what is the file type that caused the issues.
@ddementieva @ashumilova - this is a good request, as there are going to be file types that trigger unexpected behaviors. Is this posisble with a configuration or a customization today?

[shadowcodex]

It is a javascript file. :)

[traugdor]

I've seen this, too, on my own box just working with MeteorJs or NodeJs code. Similar web-based IDEs have this option, why not Che?

Also what about unsupported file types? If the error checker doesn't recognize the file type or the language within, it could cause some major headaches with the warnings and errors filling up the screen.

[TylerJewell]

@traugdor - this is unrelated to unsupported file types. It has to do with challenges and issues with the Orion editor, which treats javascript differently than all other editors. javascript is a special case language as a result, and needs special treatment. part of the issue is that orion's language services have not been cleanly abstracted to run on the server-side, so we are using their browser-side analysis, and this makes che work with all languages inconsistent.

[shadowcodex]

@TylerJewell Interesting. I noticed that it used Orion.

Is there a writeup to why CHE chose orion and not codemirror/ace? As those both have language services that are very complete for tons of languages.

[TylerJewell]

We used to be codemirror. It has horrible API and is not easy to extend. We have a major requirement with Che to make it customizable with plugins that span server-side and client-side. The editor selection is part of that and wrapped with our extension framework.

We chose orion for numerous reasons:

1. best globalization support
2. cleanest extension API, so we could wrap it into our global extension possibility
3. has a commercially-friendly license
4. is eclipse IP-certified, which helps with large vendors like SAP that need to do complex embedding scenarios.

[shadowcodex]

I agree that codemirror's API is horrendous.

Thanks for the explanation, all makes sense. Now let's see what we can do about adapting Orions annotations for javascript (Maybe allowing one to drop a lint file configuration in the folder of the project). A user provided lint file would make it so anyone could create an annotation scheme based on the language they are using.

[thyeun]

@shadowcodex for eclipse che, the annotation scheme actually are already done when you choose your workspace (meaning that you already choose the correct stack for your project).

An example, if you choose a workspace of Node.js, than the annotation scheme will be based on javascript. except that you created a blank workspace and create a new project and did not define the template, than you might not possible to have a correct annotation scheme.

[shadowcodex]

@thyeun We run custom docker scripts to build our workspaces. Would be nice if the workspace type could be set to nothing to set no annotations.

So to create a custom annotation scheme we would have to make a new workspace type?

[thyeun]

@shadowcodex you can create a custom stack (instead of using the current existing one), and define the language that you prefer and using it as your "private workspace".

you can have a further reading on below link

https://eclipse-che.readme.io/docs/stacks

hope it clear your doubt.....

[shadowcodex]

@thyeun That doesn't really solve the annotation problem. What if you have multiple types of files in your project? How do you define annotation for them?

Need something in the project folder that can be setup as a config for the different file types in that project.

[TylerJewell]

Stacks do not solve this particular problem. This has to do with the way Orion exposes these items and our extension framework embraces them. There _are_ ways to customize these things. We have some documentation here that is at the extension level, which is a bit of a heavy solution. But we need @ashumilova to comment if this is configurable at the editor level outside of an extension.

https://eclipse-che.readme.io/docs/code-editors

[ashumilova]

Stacks provide your environment configuration, but really do not affect any of editor settings. Unfortunately, right now Che is not providing possibility to configure editor settings to the end user, but it would be great to add it.
Putting lint file in the root of the project won't help as well, cause our orion plugin doesn't analyze whole project structure, only current file (same with tern-project stuff etc), but will try to investigate how to implement this.
Tried to comment blocks of JS with following :
/*ignore jslint start*/ /*ignore jslint end*/ or
/*jshint ignore:start*/ /*jshint ignore:end*/
and no luck, same on Orion hub, seems like having issue with that.
So the proposed option is to remove js extension here.

Thank's for mentioning about this problem and your feedbacks. Will do our best to solve this.

[shadowcodex]

Well I am glad it is on your radar for now. That is all that I can ask. Thanks for taking the time to look into this.

[shadowcodex]

@ashumilova I figured it out. After you showed it to me with those ignore blocks I looked up eslint docs.

Seeing as the editor provided eslint-env markup to tell it that certain things are global I tried this...

/* eslint no-unreachable: "off", no-else-return: "off" */

And it worked. It took away the big block of stuff based on the no-else-return rule being turned off..

So for eslint configuration it is a file by file thing, but works!

@TylerJewell @thyeun

[TylerJewell]

@shadowcodex - great innovative solution.

@ashumilova - so it seems that our longer term options here are one of two items:
1: We could provide the Orion server within our worksapce, which provides cross-file analysis, such as for linting. But that seems like a lot of weight to force into a workspace just to get some additional Orion analysis capabilities.

2: Or, could we implement some support for eslint configuration files in the project structure? It would be something temporary like searching for an eslint configuration file and then activating its contents inside each javascript file that is opened.

Both are fairly undesirables. And it seems that the better option would be to allow users to customize various linting and syntax analysis configuration either at the Che server level, or perhaps they should do it within a workspace configuration.

Is this your take?

[mjshashank]

I still face this issue with React projects where mainly JSX syntax is not recognised and the editor is full of errors and warnings.

Adding the necessary annotations to every file seems very cumbersome for our projects and use-case.

Could you point me to where I can make the change to remove the js extension responsible for the linting since that would be the best way to handle this temporarily?

[slemeur]

Closing this issue as the new version of Eclipse Che is providing a new editor (Monaco, the same as VS Code)