Having issues closed and locked without addressing them or a chance to reply is very discouraging

[slikts]

#594 was locked without giving a chance to respond to the reasons for closing it, and the reasons for closing are unrelated to the issue. The issue was not about removing the settings but moving them out of tsconfi.json, which would not affect their usefulness and bring it in line with the normal practice of having a separate config file. The benefits would be the lack of ambiguity and ease of management. I was waiting for the results of the discussion to make a PR, but I don't see how it's possible to contribute if discussion about issues is denied.

[basarat]

but I don't see how it's possible to contribute if discussion about issues is denied.

Basically its to say "no more discussion please" we will not move the existing options out of tsconfig.json. It is opinionated ... but it is with the other team members and projects approval. And people have even expressed interest of moving tsd.json into tsconfig.json : DefinitelyTyped/tsd#200

Thanks for your interest 🌹

[slikts]

The "people" is one person, and in that issue there's the same counter-arguments that extending tsconfig.json is nonstandard and that managing files is easier. The other example you gave of a project doing this is your own project (grunt-ts).

[nycdotnet]

Hi @slikts,

We truly appreciate your feedback, and we'd love to have you contribute on this particular issue in the ways I suggested in the other thread (documentation, advocating the TS team for an official third party mechanism in tsconfig.json, etc.). We'd also gladly accept any contributions you could offer for our other up for grabs issues.

One of the hard parts of managing an open source project is that sometimes you have to say "No" to passionate people who want the project to go in a different direction. We've discussed this issue, and the answer is "No" until something mandates such a breaking change.

If you still feel very strongly about this issue, the project is MIT licensed so you are free to spend your time and effort maintaining a fork of atom-typescript that implements the config file change and any other changes that you see fit. If that seems like a lot of work, please consider that this is what Bas already does for free.

Kind regards,

-Steve O

[slikts]

advocating the TS team for an official third party mechanism in tsconfig.json

How would it make sense for me to advocate for something I'm asking to change because it's a bad idea? If anything, I would strongly argue against it. I see no advantages to putting tangentially related configs in tsconfig.json, because it makes it harder to manage them and is not the normal practice. atom-ts and TS are separate things and should have separate configs. There is a breaking change needed in any case because filesGlob is confusingly similar to files, so the solution would be to do it right and put it in a separate file, but you're disallowing even a discussion about it. Even if you disagree, the least you could do is allow a discussion if you expect contributions.

[nycdotnet]

I believe that I fully understand your position; it is a reasonable one, and you've supported it with several arguments.

The TypeStrong position is that we don't wish to take a breaking change on this issue at this time because breaking changes are bad for our thousands of users. As the maintainers of this project, that is our prerogative and I ask that you please respect that.

When conditions change, we are always willing to re-evaluate our position. I don't believe further discussion on this issue would be useful until then.

Thank you for your feedback.

[slikts]

There's a suggestion now for tsconfig.json to support comments. If this was implemented, you would be stripping the comments, just like you are stripping the formatting now.

What's the problem with leaving an issue for an unresolved problem open? Someone else might have some more useful input. Instead, it's being closed as if it's resolved.