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

Move compile on save to ide key #324

Closed
MicahZoltu opened this issue May 2, 2015 · 4 comments
Closed

Move compile on save to ide key #324

MicahZoltu opened this issue May 2, 2015 · 4 comments

Comments

@MicahZoltu
Copy link

TL;DR: Provide a way to disable the build part of atom-typescript but retain the IDE features (auto-complete, syntax highlighting, etc.)

I have a project that leverages a number of technologies that require a build step. I am using gulp as my build system. I would like to be able to use atom-typescript, but I do not want it to be building things for me, I just want it for the IDE features.

From what I can tell, there isn't a way that I can disable the build-system features of atom-typescript while retaining the rest of the features. gulp-typescript uses tsconfig.json, so as long as atom-typescript continues to use tsconfig.json for its configuration then everything should stay in sync.

The reason auto-compilation is a problem is because my build system does more than a default TypeScript compile. After the typescript files are built, they need to be processed and put in the correct location. atom-typescript is currently creating intermediate files that should not exist for longer than it takes to run a build.

Also, atom-typescript doesn't support rootDir yet, though I imagine this is a temporary problem.

@MicahZoltu
Copy link
Author

I just found out about: https://github.com/TypeStrong/atom-typescript/blob/master/docs/faq.md#i-dont-want-atom-typescript-compiling-my-js

This is a workaround for now, however I may have other tools that I do want to compile-on-save. In general, I think it is a bad idea to combine atom-typescript configuration with general typescript configuration. The same goes for filesGlob, this should go in an atom-typescript file or nested inside an atom-typescript object in the tsconfig.json. In the case of the latter, there should be a standard way of extending tsconfig.json that various IDEs can leverage when they want to add their own IDE-specific (non-standard) options such that they don't collide with other tools.

@basarat
Copy link
Member

basarat commented May 4, 2015

that various IDEs can leverage when they want to add their own IDE-specific (non-standard) options such that they don't collide with other tools.

Agreed. We should move compileOnSave under an ide key.

@basarat basarat self-assigned this May 4, 2015
@basarat basarat changed the title Don't compile. Move compile on save to ide key May 4, 2015
@MicahZoltu
Copy link
Author

Is there be a situation where you would _not_ want Visual Studio or IntelliJ to compile on save but you _would_ want atom to compile on save?

If the answer to the above question is yes, then I believe this should be put into an atom or atom-typescript key. If no one can come up with a reason why you wouldn't want the rule to apply across IDEs then I think ide is a good key name.

If it is going to end up in a general ide key, it may be a good idea to get feedback from the community (outside of atom-typescript) on this to better coordinate with other IDEs on the matter, to avoid having to change again if Visual Studio or IntelliJ decide to do something similar but under a different key.

@basarat
Copy link
Member

basarat commented May 4, 2015

If it is going to end up in a general ide key, it may be a good idea to get feedback from the community (outside of atom-typescript) on this to better coordinate with other IDEs on the matter

We did discuss it : microsoft/TypeScript#2326 I just left another comment microsoft/TypeScript#2326 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants