Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Could you reconsider the "tsconfig.json" default value of "strict: false"? #12895

Closed
phryneas opened this issue May 14, 2020 · 6 comments
Closed

Comments

@phryneas
Copy link
Contributor

phryneas commented May 14, 2020

Feature request

I just noticed that next.js defaults to strict: false in the generated tsconfig.json.

The reasoning behind seems to be (quoting @Timer from ##7716):

Users who are testing out Next.js' TypeScript support shouldn't be stuck behind a failure to compile screen. This will allow advanced users to opt into strict: true when they're ready.

I would ask you if it were possible to reconsider this.

Running tsc --init creates a tsconfig.json with strict: true since that option was introduced with TypeScript 2.3.
An advanced user will probably not notice this for quite some time, because they assume that TypeScript offers it's full (default-configuration) functionality out of the box, just wondering about unsound behaviour here and there until it piles up and finally going to strict: true has actually become a chore.

If there are any strict options that are not working well with next.js, it's still an option, to default to strict: true in combination with strictThatHurts: false and mentioning to that in the documentation.

I have to admit that I'm not even a next.js user myself (athough it is in my list of stuff to check out!), but got a report by a user of our library (@reduxjs/toolkit) about strange behaviour - which we could attribute back to strictNullChecks being disabled. The user was quite irritated because they had assumed that strict would be enabled.

So I don't really believe that you're doing your users a service with this default :(

As an alternative, if you could not commit to a strict: true default, maybe it might be an option to actively ask the user for feedback on it when the tsconfig.json would be filled with the default values - and let the user decide between "loose" and "strict" behaviour?

@phryneas phryneas changed the title "strict: false" is a very dangerous default for the tsconfig.json Could you reconsider the "tsconfig.json" default value of "strict: false"? May 14, 2020
@danilofuchs
Copy link

I have personally experienced the pain of trying to migrate a huge project from strict: false to strict: true, and I can say it was one of my worst experiences ever. Everything starts to fall apart and it becomes impossible at a certain point. I argue less experienced programmers will never notice strict is false and will run into avoidable bugs, only to later find out about strict and eventually giving up on the codebase migration.

@tanvp112
Copy link

tanvp112 commented May 15, 2020

User assumption is not the responsibility of the framework, I supposed. Note typescript is not perfect, the trans-piled code sometimes can cause unexpected behavior, too.

I think the default should stay as false. User can change to true anytime as they see fit. Or better, checkout https://github.com/facebook/prop-types

@timneutkens
Copy link
Member

A question could potentially be added as part of #8128.

@Timer
Copy link
Member

Timer commented Sep 10, 2020

We're going to leave this default as false for now. Most users who are ready for strict: true will be creating their own tsconfig.json and not be relying on Next.js to do it.

@Timer Timer closed this as completed Sep 10, 2020
@filipesmedeiros
Copy link

hey team, love the work. since a flag --typescript / -ts was added for the next-app cli, is there any chance this config should be changed to match that one? (that currently enforces strict by default)?

@balazsorban44
Copy link
Member

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@vercel vercel locked as resolved and limited conversation to collaborators Jan 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants