TypeScript nature

@piotrtomiak

typescript.java can manage completion, hover, validation for _.ts, ._jsx, *.tsx and even *.js file (TypeScript Salsa).

Today completion, hover, validation are executed for thoses files without converting the project to TypeScript (Like Convert to JavaScript project).

It means that if user install typescript.java, the whole project of workspace which have _.ts, ._jsx, *.tsx, *.js will consume TypeScritpt tsserver.

This issue is to define the rules when tsserver must be consumed or not (I would liek to avoid doing "Convert To TypeScript project".

The case that I see which is hassle is for *.js files. My idea is to consume tsserver only if project has jsconfig.json.

@piotrtomiak please give me your opinion about this issue if you decide to use typescript.java. Thanks!

Do you mean consume tsserver if project has a tsconfig.json，isn’t it? I think is a good idea.

Can be good having a way to disable the default behavior.

I like the approach with Tern.java, where you tie it to presence of .ternproject. I think that to provide good content assist, you need a tsconfig.json anyway, so tying support for ts to it, seems to be a good approach. You can always provide a "Configure for TypeScript" action, which will crate a default tsconfig.json file. That file is also a place where you can store a lot of configuration.

Check out https://github.com/TypeStrong/atom-typescript/blob/master/docs/tsconfig.md , which says that Atom is using a custom filesGlob property which is list of minimatch-style includes/excludes (you can do exclude by prefixing pattern with "!") and editor ensures that list of files in files field is kept up to date. I really like that approach.

+1 to use tsconfig.json to store configuration properties like Atom-typescript. I will be good to use "the same properties" to allow edit same project in both editors/IDEs

@piotrtomiak

My first idea was to do like tern.java (as @piotrtomiak said):

if project has tsconfig.json, it's a TypeScript project
if project has jsconfig.json, TypeScript Salsa must be used

But it means that there are several (perhaps little) limitations with that:

you need to have a tsconfig.json although tsserver is able to work without it (you set the options in the args of the node command line), but it is really used today?
tsconfig.json must be in the root of the project. So you will not able to consume tsserver if your tsconfig.json is not in the root of the project. Is it a problem? More it seems that TypeScript will support multiple tsconfig.json

You can always provide a "Configure for TypeScript" action, which will crate a default tsconfig.json file. That file is also a place where you can store a lot of configuration.

Yes, it was my idea too:) (like tern.java)

Check out https://github.com/TypeStrong/atom-typescript/blob/master/docs/tsconfig.md , which says that Atom is using a custom filesGlob

Yes I have seen that, TypeScript guys are discussing about that microsoft/TypeScript#1927 Hope tsserver will support it.

+1 to use tsconfig.json to store configuration properties like Atom-typescript. I will be good to use "the same properties" to allow edit same project in both editors/IDEs

Totally agree, it was the reason why I don't want to use classic Eclipse Nature (stored in the .project) like I have done with tern.java.

If you think my limitatiosn that I hav eexplained below are not important, I will implement TypeScript nature with exist of tsconfig.json or jsconfig.json in the root of the project.

Thanks @micaelgallego @piotrtomiak for your answer!

I think that the limitation of storing tsconfig.json in the root of the project is a serious limitation. The layout of a project generated with the official angular-cli stores the tsconfig.json in a subfolder, not in the root of the project.

If there are the possibility to specify the location of tsconfig.json, it is not a problem expecting it in the root of the project by default (because you can change it if you want).

I think that the limitation of storing tsconfig.json in the root of the project is a serious limitation. The layout of a project generated with the official angular-cli stores the tsconfig.json in a subfolder, not in the root of the project.

It was my fear -( So it's not possible to detect autmaticly if project is a TypeScript project. I would like to avoid scan the whole files of project to try to find tsconfig.json

If there are the possibility to specify the location of tsconfig.json, it is not a problem expecting it in the root of the project by default (because you can change it if you want).

If we do that, it means that we cannot detect automaticly that it's a TypeScritpt project (if we import the existing project inside Eclipse).

But I'm afraid that it's the only solution. We could:

check if project has tsconfig.json location specified in a project preferences.
othewise check if tsconfig.json exists in the root project.

We could provide a default (global) preferences too where tsconfig.json must be checked like:

tsconfig.json (project root)
app/tsconfig.json

In other words, my idea is to provide in the UI preferences TypeScript (project and global) a list of path where tsconfig.json must be searched (by default it's tsconfig.json and app/tsconfig.json)

When user want to add a new path, it does "Convert to TypeScript project" and select her tsconfig.json path.

"Convert to TypeScript project" open a dialog which contains :

a checkbox (select existing tsconfig.json) + text field to select an existing tsconfig.json,
a checkbox (create new tsconfig.json) + several text fields (compiler options, etc) , combo to create a tsconfig.json

If user rename folder which contains tsconfig.json, list should be updated. But I will not to do that for the moment. I would like to create a release soon.

What do you think about that?

It looks good to me. Automatically detect tsconfig.json in well known locations and let user specify a custom one.

Only one detail. If you want to recognize angular-cli projects out-of-the-box, please consider that tsconfig.json file is located in src/tsconfig.json, not in app/tsconfig.json.

@micaelgallego

file is located in src/tsconfig.json, not in app/tsconfig.json.

Thanks @micaelgallego for your info! So by default it will be :

'/'
'/src'

(without tsconfig.json, because you can have jsconfig.json too)

I have never used angular-cli. Please note I have planned to create Angular2 Eclipse https://github.com/angelozerr/angular2-eclipse/wiki/RoadMap Don't hesitate to add comments, ideas, fix comments, etc and creates issues https://github.com/angelozerr/angular2-eclipse/issues

I know angular2-eclipse project. I'm very excited about it ;) I'm impatient to use it.

I've just write an issue in it: angelozerr/angular-eclipse#4

If I have some spare time, I promise to contribute to the plugin ;)

Thank you for your awesome work.

I know angular2-eclipse project. I'm very excited about it ;) I'm impatient to use it.

Cool:) But to be honnest with you, I have just started some POC to study limitation of Eclipse WTP. I'm afraid that those limitation will not be fixed for Neon -(

But I can start to implement basic feature like completion for *ngFor inside HTML editor.

My first goal today is to release typescript.java with basic feature for TypeScript (completion, hover, hyperlink, validation and perhaps tsc). After that I will try to start Angular2 Eclipse.

If I have some spare time, I promise to contribute to the plugin ;)

Any contribution are welcome!

Thank you for your awesome work.

Thanks!

to be honnest with you, I have just started some POC to study limitation of Eclipse WTP. I'm afraid that those limitation will not be fixed for Neon -(
But I can start to implement basic feature like completion for *ngFor inside HTML editor.

IMHO It is more important for angular2-eclipse to play with well-know tools (angular-cli, live-serve, browser-sync...) than template auto-completion. Moreover, today there is no other plugin for Atom, WebStorm, etc... that support this kind of functionality, with the exception of VSCode prototype. But it is your project and you define your priorities ;)

Use "Salsa" preferences to know if completion, hyperlink, validation,

Ok, after playing with tsserver and VSCode, I decided to do the same thing than VSCode. In other words, I consume tsserver each time completion, validation, hover, hyperlink is done inside *.ts, *.tsx, *.jsx file opened with JSDT Editor. tsserver is able to support TypeScript and JSX without tsconfig.json, so I find it's shame to remove this feature.

The big problem was with JavaScript file *.js. Since TypeScript 1.8.0, TypeScript is able to support inference engine with *.js JavaScript files (called Salsa). Sometimes you wish to use Salsa, sometimes not. You wish to use just JSDT and not Salsa.

To support the enable/disable of Salsa, I have added a new preferences (in global and not in a project properties)

Never : will never use Salsa when completion, hover, etc is done inside JS file editor.
Every Time: will use every time Salsa when completion, hover, etc is done inside JS file editor.
When no JSDT nature: will use Salsa when completion, hover, etc is done inside JS file editor only if project has not JSDT nature.

By default "When no JSDT nature" is selected. The enable/disable of Salsa could be improved but I would like to develop other more important features.

See https://github.com/angelozerr/typescript.java/blob/master/eclipse/ts.eclipse.ide.core/src/ts/eclipse/ide/internal/core/resources/IDEResourcesManager.java#L93

Another thing is that TypeScript menu property is every displayed when project properties is opened.

See https://github.com/angelozerr/typescript.java/blob/master/eclipse/ts.eclipse.ide.core/src/ts/eclipse/ide/internal/core/resources/IDEResourcesManager.java#L80 It could be improved by searching tsconfig.json, but I think it's not very important for the moment to do that.

Hope you will like it. Any feedback are welcome!

Show "TypeScript" project properties if there is one or several

@micaelgallego

@micaelgallego @piotrtomiak see https://github.com/angelozerr/typescript.java/wiki/TypeScript-BuildPath#typescript-nature if you are interested to know the rules how I manage "TypeScript Nature" without "Eclipse Nature".

I have decided to do that according the comments #54 (comment)

Navigation Menu

Repository navigation

TypeScript nature #12

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

TypeScript nature #12

Description

Activity

micaelgallego commented on Mar 5, 2016

piotrtomiak commented on Mar 5, 2016

micaelgallego commented on Mar 5, 2016

angelozerr commented on Mar 5, 2016

micaelgallego commented on Mar 5, 2016

angelozerr commented on Mar 6, 2016

micaelgallego commented on Mar 6, 2016

micaelgallego commented on Mar 6, 2016

angelozerr commented on Mar 6, 2016

micaelgallego commented on Mar 6, 2016

angelozerr commented on Mar 6, 2016

micaelgallego commented on Mar 6, 2016

angelozerr commented on Mar 7, 2016

angelozerr commented on Apr 29, 2016

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions