Next.js: next v9 typescript dev experience - thoughts

[jeremy-coleman]

a few observations.
1) lint "failures" shouldn't stop the app from compiling. it does now , similar to CRA.
2) fixing lint failures often requires restarting the server because the watchers wont trigger.
3) add a check for a tsconfig at process.cwd() , and extending it if it exists. For example, if i run 'next src' in a project with src/pages/.. , the current behavior won't use the root tsconfig.
4) the tsconfig paths webpack plugin works with babel (because it modifies the webpack resolution), so you should just use it by default imo(it won't do anything if the user hasn't set up a baseUrl or path alias anyway)
5) The linter runs on all files, basically negating the HUGE benefit of next's lazy compilation.
IMO, just remove the linter completely and let users run it independently

update:
create a new issue here https://github.com/zeit/next.js/issues/7908
corresponding repo
update: https://github.com/jeremy-coleman/next-tsc-proposal/tree/gulp

going to close this, to focus on a solution

[kachkaev]

Similar thoughts in https://github.com/zeit/next.js/issues/7687. I wish we could simply disable TypeScript linting during dev and build without having to apply a hacky workaround.

[timneutkens]

This doesn't follow the issue template 😢

[elken]

Agreed. I, as I'm sure most people do, already have linting on my editor and it would be nice to either disable completely or removing the strictness.

[Janpot]

It kind of breaks the development flow for me . While I'm working on something, I don't need 100% strict type checking all the time, often I don't care about implicit any types and things like that until I've fully understood the problem and solution of the particular thing I'm working on. Imagine a linter preventing you from running your code because you didn't put a semicolon.

[Timer]

Closing in favor of https://github.com/zeit/next.js/issues/8331, someone can feel free to implement this feature!