You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
In tsc cli can't override declaration to false when tsconfig.json contains declarationDir option? #21443
Looking at this again, I do not think we want to change this behavior really.. tsconfig.json allows for such overrides using extends and using null as an override value. i do not think the value we get from allowing this on the command line is wroth handling empty strings in all of our compiler options.
Mohamed Hegazy (@mhegazy) Consider this issue and its fix: ezolenko/rollup-plugin-typescript2#52. Not only rollup-plugin-typescript, other plugins, e.g. ts-loader, which provides override feature and calls tsModule. parseJsonConfigFileContent from tsproxy inside, have this issue that once we specified the declarationDir in a base tsconfig.json we have no ways to cancel it.
rollup-plugin-typescript2 fixed it after this issue submitting by re-writing the parsed value of declarationDir to null if ppl try to override it by setting a nulldeclarationDir, the procedure is consuming tsconfig.json and user's overrides and then call tsModule. parseJsonConfigFileContent to get parsed configs, modify the parsed declarationDir option if ppl setted declarationDir to null.
Maybe there are many other plugins have the same issue, it is exhausted to fixing one by one. moreover, declaration cancelation is not documented by official site(seems only exists in this pr:#18058), normal users don't know the right way to cancel the declaration through tsconfig.json extending(json scheme defined it as string type, it is also a problem, need official document to back to update it), and plugin authors don't sure the right way to generated the final TS configs to feed to next procedure.
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.
Looking at this again, I do not think we want to change this behavior really.. tsconfig.json allows for such overrides using extends and using null as an override value.
I'd like to ask to reconsider. First, it is not obvious that one can use null. Second, VS Code warns about null: Incorrect Type, expected "string".
The whole behavior is quite confusing. It would be really nice if simple and obvious declaration: false turned off the generation of declarations, without the need to investigate, search the web, find some issues on Github and comment on those! :)
And now, also gulp-typescript doesn't work with "declarationDir": null, complains (see below). And changing docs and fixing schema is not a proper solution to the whole thing, in my opinion, we just cover up the actual problem: When user states (in tsconfig or via command line) that he/she doesn't want declarations via declaration: false, that should be enough, there is no need for tricky and unobvious extra actions, such as changing declarationDir for some reason. Please reconsider. At the moment: it is unobvious to user how to deal with this issue: 1. Confusing command-line 2. Unexpected and not recommended by VS Config tsconfig.json modification 3. Failing gulp-typescript.
I think these are very different cases. For declaration/declarationDir, they can't exist without each other. outDir and outFile can stand on their own.
To me, it is very natural that declarationDir should be required only when declaration is true. When declaration is false, it shouldn't matter what the value of declarationDir.
Here's my use case. We have a parent, core project, where we generate declarations for sub-projects to consume. In sub-projects we have tsproject.json files that extend the parent one, but set declaration to false. And we get the error for same reason. To me this is clearly a bug.
I am not sure why we are even debating this. I am probably missing some insight, but the current behavior is so weird and blatantly incorrect (to me, at least). I have to be missing something! :)
i am not sure either :) I believe we have a feature that accomplish the task in general fashion for all options. you are arguing that this should be done differently on a one-per-one basis.
I believe we have a feature that accomplish the task in general fashion for all options
With all respect, I'd disagree. You are not fully accomplishing the task, since users cannot adjust the configuration via command line properly. If the config file states that declarations must be created, and user doesn't want them, he/she CANNOT override this behavior via command line switch. This is a problem. One have to go to the config file and comment those settings out, which is not good for the command line use-case.... :)
Activity
Kingwl commentedon Feb 5, 2018
TS6044because empty string is falsey https://github.com/Microsoft/TypeScript/blob/master/src/harness/unittests/commandLineParsing.ts#L227has a unit test similar for it
mhegazy commentedon Feb 5, 2018
Looking at this again, I do not think we want to change this behavior really.. tsconfig.json allows for such overrides using
extendsand usingnullas an override value. i do not think the value we get from allowing this on the command line is wroth handling empty strings in all of our compiler options.zheeeng commentedon Feb 6, 2018
Mohamed Hegazy (@mhegazy) Consider this issue and its fix: ezolenko/rollup-plugin-typescript2#52. Not only rollup-plugin-typescript, other plugins, e.g. ts-loader, which provides override feature and calls
tsModule. parseJsonConfigFileContentfromtsproxyinside, have this issue that once we specified thedeclarationDirin a basetsconfig.jsonwe have no ways to cancel it.rollup-plugin-typescript2 fixed it after this issue submitting by re-writing the parsed value of
declarationDirtonullif ppl try to override it by setting anulldeclarationDir, the procedure is consumingtsconfig.jsonand user's overrides and then call tsModule. parseJsonConfigFileContent to get parsed configs, modify the parseddeclarationDiroption if ppl setteddeclarationDirtonull.ts-loader also can't cancel declaration:
Maybe there are many other plugins have the same issue, it is exhausted to fixing one by one. moreover, declaration cancelation is not documented by official site(seems only exists in this pr:#18058), normal users don't know the right way to cancel the declaration through tsconfig.json extending(json scheme defined it as string type, it is also a problem, need official document to back to update it), and plugin authors don't sure the right way to generated the final TS configs to feed to next procedure.
mhegazy commentedon Feb 6, 2018
parseJsonConfigFileContentthird argument is a set of overrides.. why is not sufficient for this scenario.. i.e.:typescript-bot commentedon Feb 22, 2018
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.
vvs commentedon Jun 21, 2018
Hi Mohamed Hegazy (@mhegazy)
I'd like to ask to reconsider. First, it is not obvious that one can use
null. Second, VS Code warns aboutnull: Incorrect Type, expected "string".The whole behavior is quite confusing. It would be really nice if simple and obvious
declaration: falseturned off the generation of declarations, without the need to investigate, search the web, find some issues on Github and comment on those! :)mhegazy commentedon Jun 21, 2018
That is a JSON feature really. we would be happy to take a PR to the docs to make that clear as well.
This is coming from the schema in https://github.com/SchemaStore/schemastore/blob/master/src/schemas/json/tsconfig.json. Feel free to send a PR to update it, and tag me on it.
vvs commentedon Jun 21, 2018
Thanks for quick response, much appreciated!
And now, also
gulp-typescriptdoesn't work with"declarationDir": null, complains (see below). And changing docs and fixing schema is not a proper solution to the whole thing, in my opinion, we just cover up the actual problem: When user states (intsconfigor via command line) that he/she doesn't want declarations viadeclaration: false, that should be enough, there is no need for tricky and unobvious extra actions, such as changingdeclarationDirfor some reason. Please reconsider. At the moment: it is unobvious to user how to deal with this issue: 1. Confusing command-line 2. Unexpected and not recommended by VS Config tsconfig.json modification 3. Failing gulp-typescript.This issue affects things all over the place :)
mhegazy commentedon Jun 21, 2018
so that rational works for
--declarationbut what about--outDir? what about--outFile? should these also have a flag that say--outDirEnabled?vvs commentedon Jun 21, 2018
I think these are very different cases. For
declaration/declarationDir, they can't exist without each other.outDirandoutFilecan stand on their own.To me, it is very natural that
declarationDirshould be required only whendeclarationis true. Whendeclarationis false, it shouldn't matter what the value ofdeclarationDir.Here's my use case. We have a parent, core project, where we generate declarations for sub-projects to consume. In sub-projects we have
tsproject.jsonfiles that extend the parent one, but setdeclarationto false. And we get the error for same reason. To me this is clearly a bug.I am not sure why we are even debating this. I am probably missing some insight, but the current behavior is so weird and blatantly incorrect (to me, at least). I have to be missing something! :)
mhegazy commentedon Jun 21, 2018
i am not sure either :) I believe we have a feature that accomplish the task in general fashion for all options. you are arguing that this should be done differently on a one-per-one basis.
vvs commentedon Jun 22, 2018
With all respect, I'd disagree. You are not fully accomplishing the task, since users cannot adjust the configuration via command line properly. If the config file states that declarations must be created, and user doesn't want them, he/she CANNOT override this behavior via command line switch. This is a problem. One have to go to the config file and comment those settings out, which is not good for the command line use-case.... :)
Added null to declarationDir definition (#1042)