Skip to content

Add no-compile option to tsconfig #2326

Closed

Description

Some users want to use the built-in compilation of their IDE, but some want to use grunt or gulp. If you want to use grunt or gulp for compilation, you need to disable compilation in your IDE. Since a big team can use multiple IDEs, I think this should be implemented in tsconfig.json.

Suggestion: Add a new option to tsconfig.json to disable the compilation in the IDE ("compile on save"), which defaults to false.

Example:

{
    "disableCompileOnSave": true,
    "compilerOptions": {
        "module": "commonjs",
        "noImplicitAny": true
    },
    "files": [
        "foo.ts",
        "bar.ts"
    ]
}

If an IDE finds a config file with this option, it shouldn't compile the project, but it should give auto completions, type errors, etcetera. If a build tool sees this option it should ignore it, because you use an IDE always for writing, sometimes for building and you use a build system always for building.

Activity

  1. danquirk commented on Mar 12, 2015

    @danquirk
    Member

    You mean full build not compile on save right? Compile on save is already toggleable in VS and using (or not using) --watch on the command line. It sounds like you want something similar to this #2294 but provided in tsconfig?

  2. ivogabe commented on Mar 12, 2015

    @ivogabe
    ContributorAuthor

    Yes, that's what I meant. It should be something like disableIdeCompilation or disableCompilation then.

  3. mhegazy commented on Mar 12, 2015

    @mhegazy
    Contributor

    Your IDE build is triggered by the msbuild targets in your project file. if you want to stop that, open your project file, and comment out the reference to Microsoft.TypeScript.Targets, and no build will occur. no need for a different file here :)

  4. ivogabe commented on Mar 12, 2015

    @ivogabe
    ContributorAuthor

    Mohamed Hegazy (@mhegazy) Unless someone else in your team uses another editor, like Atom. You can disable it in Atom, but defining it once in tsconfig would be better.

  5. ivogabe commented on Mar 16, 2015

    @ivogabe
    ContributorAuthor
  6. johnnyreilly commented on Mar 16, 2015

    @johnnyreilly

    As I understand it this switch would support those users who are using Gulp or Grunt to do their TypeScript compilation and they don't want Visual Studio / atom-typescript / sublime etc to get involved in doing a build.

    As Mohamed Hegazy (@mhegazy) says we can already cater for this in Visual Studio by tweaking the project file.

    As regards atom-typescript etc I understand there's a an agreement that we can extend the tsconfig.json file already (as long as we don't conflict with existing settings.

    That being the case I'm not sure this needs an official tsconfig.json flag (although I guess it'd be nicer?) Is it enough if we just extend it unofficially?

    Basarat Ali Syed (@basarat) - do you have a view on this?

  7. ivogabe commented on Mar 16, 2015

    @ivogabe
    ContributorAuthor

    John Reilly (@johnnyreilly) That's a good summary. There is a big advantage for this to be official, since if it's official, all editors should support it. That makes it easier for these users: they can configure this option once and it will be disabled in all editors. That's very useful if you have a big team or an open source project.

  8. danquirk commented on Mar 16, 2015

    @danquirk
    Member

    I'm inclined to agree. If enough people want this in enough different scenarios then there's value in just standardizing the name of the flag rather than having some people use noCompile and someone else use skipCompile and someone else use yet another option.

  9. basarat commented on Mar 16, 2015

    @basarat
    Contributor

    I recommend compileOnSave (default true). Atom-typescript already supports this as a package option, that you can even configure per project : https://github.com/TypeStrong/atom-typescript/blob/master/docs/packages.md#manage-your-projects

    👍 on moving this into tsconfig.json. I'll do that.

    PS: Having a negative like disable in a variable name is a bad idea. Double negation is not easy for the human brain. "disableCompileOnSave": false,. I've done this myself too and sometimes it does make sense, so no judgement ❤️

  10. ivogabe commented on Mar 17, 2015

    @ivogabe
    ContributorAuthor

    Basarat Ali Syed (@basarat) I chose for disable since it can then default to false, and undefined is false-ish. But I can also life without disable. As pointed out by Dan Quirk (@danquirk) compileOnSave might not be the right name for it, since that would mean that Visual Studio should only disable automatic compilation, not the compile button. I'd call it something like ideCompilation, or maybe better: externalCompilation, which defaults to false and doesn't have a double negotiation. externalCompilation: true would mean you're using Gulp, Grunt, Jake etcetera.

  11. basarat commented on Mar 17, 2015

    @basarat
    Contributor

    Dan Quirk (@danquirk) compileOnSave might not be the right name for it, since that would mean that Visual Studio should only disable automatic compilation, not the compile button

    I specifically want to disable "compile" OnSave. For Atom-TypeScript build is an explicit option triggered by the user. If they don't trigger it, it doesn't happen. Compile on save is what happened as a side effect of saving and so it needed configuration.

    I guess you want to disable all IDE compile. That seems like a Visual Studio / exclude from MSBuild problem, not related to other other IDEs. At the very least don't see it as an option we need to read in Atom-TypeScript.

  12. basarat commented on Mar 17, 2015

    @basarat
    Contributor

    Ivo Gabe de Wolff (@ivogabe) perhaps compileOnBuild for visual studio ?

  13. ivogabe commented on Mar 17, 2015

    @ivogabe
    ContributorAuthor

    Basarat Ali Syed (@basarat) Do you mean adding two different options to tsconfig.json? I think it would be better to make these two one, especially because many (all?) users want to enable them both, or disable them both. I think disabling a build option hidden in a submenu isn't a problem, since setting this option means you shouldn't compile TypeScript from an editor since a build system should do that.

  14. 21 remaining items

  15. johnnyreilly commented on Jan 15, 2016

    @johnnyreilly

    Yay!

  16. paulvanbrenk commented on Feb 2, 2016

    @paulvanbrenk
    Contributor

    compileOnSave should be in for 1.8 final, I checked it in.

  17. johnnyreilly commented on Feb 2, 2016

    @johnnyreilly

    I've been experiencing difficulties with it... See #6782

  18. netdragonboberb commented on Nov 11, 2016

    @netdragonboberb

    .njsproj files also work for TypeScriptCompileBlocked. See also https://shauntm.com/notes/entries/231

  19. ofirgeller commented on Jan 8, 2017

    @ofirgeller

    How about compile on save for just some files? my files should not be compiled on save as I use gulp to do that. but I actually write my gulpfile as a typescript file and I need that file to compile on save.

  20. mhegazy commented on Jan 9, 2017

    @mhegazy
    Contributor

    How about compile on save for just some files? my files should not be compiled on save as I use gulp to do that. but I actually write my gulpfile as a typescript file and I need that file to compile on save.

    have to tsconfig.json files, one at the root for your gulpFile, and one in a source directory for your sources. the top one allows compile on save, the other one does not.

    regardless, i do not think you can rely on compile on save for your gulp file, as you want it to run on a CI server for instance that does not have an editor. consider using something like ts-node instead.

  21. locked and limited conversation to collaborators on Jun 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

FixedA PR has been merged for this issueSuggestionAn idea for TypeScriptVisual StudioIntegration with Visual Studio

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions