totally correct - I'm however not sure if there is a benefit in doing this?
You will almost need the exact same settings and it will not allow you to use tsc to do actual type linting - e.g. it will show you the errors in the IDE but you can't "enforce" it. That's about the only difference I can think of - so it seems using a tsconfig.json by default is a smarter choice? 🤔
What would be your use-case for it? when would you prefer a jsconfig.json over a tsconfig.json?
I would push for jsconfig.json if my team was unwilling or unable to use TypeScript (maybe mandated by high-ups). Because introducing tsc into the build would mean we would want to also introduce it in CI, and that would go against the mandate. If the team was able to adopt TypeScript, I would just do the conversion–probably incrementally. If the team was willing to look at less mainstream alt-JS options, I would push for ReasonML :-)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
totally correct - I'm however not sure if there is a benefit in doing this?
You will almost need the exact same settings and it will not allow you to use
tscto do actual type linting - e.g. it will show you the errors in the IDE but you can't "enforce" it. That's about the only difference I can think of - so it seems using atsconfig.jsonby default is a smarter choice? 🤔What would be your use-case for it? when would you prefer a
jsconfig.jsonover atsconfig.json?I would push for
jsconfig.jsonif my team was unwilling or unable to use TypeScript (maybe mandated by high-ups). Because introducingtscinto the build would mean we would want to also introduce it in CI, and that would go against the mandate. If the team was able to adopt TypeScript, I would just do the conversion–probably incrementally. If the team was willing to look at less mainstream alt-JS options, I would push for ReasonML :-)