Proposal: genarate tsconfig.json automatically when tsconfig.js is present

[constgen]

Currently consumers should manually setup a call to a function to refresh tsconfig.json. I propose to atomize this process and generate tsconfig when neutrino() is called with neutrino-typescript middleware and only if tsconfig.js is present. tsconfig.js just have to return the config that will be saved. If consumers are going to use a custom tsconfig.json they just don't need to create tsconfig.js in the project. This should always synchronize tsconfig with Neutrino config

[davidje13]

Interesting idea. In essence this would mean incorporating behaviour like https://www.npmjs.com/package/tsconfig.js but only invoke it when a build-like action is performed (rather than using a constant watcher, like it does).

Caveats:

• If a script runs tsc, neutrino() isn't invoked, so the type checking could run with an (unexpectedly) out-dated config.
  • eslint would be fine.
  • webpack / babel don't use the tsconfig.json anyway.
  • a full build would trigger this, which might be fine for most workflows (type checking will often be post-build or post-lint. But not always!)
• IDEs which use tsconfig.json won't get configuration changes until the next build (same as now except that people can choose to run rewrite-tsconfig at any time if they wish)
• It would mean that projects end up containing both a tsconfig.js and tsconfig.json, which might be confusing (although I guess no more than having the config in .neutrinorc.js and copied into tsconfig.json as it is now). Both of these files ought to be committed too.
  • I'd be more inclined to have an option in the neutrino config, like typescript({ autoRewrite: true, tsconfig: {...} }) rather than check for a tsconfig.js. 2 reasons: fewer files in the repo, and guarantees compatibility (if somebody puts something other than module.exports = neutrino().tsconfig() in the tsconfig.js when using neutrino, that's probably a mistake.

I think the first issue is a show-stopper in my mind, because it could cause confusing behaviour (in particular, anybody performing type checking before a build will find that they have to run build twice for a change to take effect, which they will probably assume is a bug in this preset).

Obviously it could be set up so that the automatic rewriting and explicit rewriting co-exist, but will people understand when they need to invoke rewrite-tsconfig?

---

If the TypeScript authors could be convinced to add some kind of scriptable startup hook to tsc then I could see something working, but given how passionately opposed they are to natively supporting tsconfig.js, I wouldn't hold out any hope for that.

Definitely open to ideas here; the current setup is far from ideal.

[davidje13]

Another possibility would be to provide a "wrapper" tsc command (maybe tscjs or something). It would ensure tsconfig.json is up-to-date then forward all args to regular tsc. That way as long as people remember to use tscjs rather than tsc it would be fine. That could be combined with your suggestion to auto-rewrite when neutrino is called so that eslint works too.

Also not great and not very in the spirit of Neutrino 9 (which aims to leave the invocation of the tooling up to the developer)

[constgen]

All you said make sense