Ability to pass a custom tsconfig for next dev

[jerrygreen]

Feature request

Is your feature request related to a problem? Please describe.

I'm bored of seeing someVar is declared but its value is never read:

I'm actively write and delete code, exploring some libraries' features - I don't want my dev server to stuck me into an error. Of course it's bad to leave them. Of course my IDE should highlight that - and for that reason, I want to have noUnusedLocals or noUnusedParameters, strict in overall. Of course there should be some pre-commit hook that will prevent me from committing this clutter into the repository. But I don’t want my dev server to throw noUnusedLocals and noUnusedParameters - I don't want it to prevent me playing with the code.

UPD. That’s okay for the default behavior, but there should be an option that these keys should be enabled by VSCode, and by linter, but not used by dev server so it won’t throw error that prevents you to do anything.

Describe the solution you'd like

I'd like an ability of passing a tsconfig path for next dev command.

Something like:

next dev --tsconfig=tsconfig.devserver.json

While I can use the original tsconfig.json for my IDE.

Describe alternatives you've considered

Well, I could make an issue for IDE (vscode doesn't support anything other than tsconfig.json too), but anyway - both sides should support that.

UPD. There's one: microsoft/vscode#12463. Still, both sides should support that.

Additional context

Idk maybe it's possible. But I don't see it from next dev --help:

[Timer]

Aren't these specific flags better suited for a linter like ESLint?

[jerrygreen]

@Timer yep, for both: linters and IDEs. Not for dev servers - it interrupts the development process. So need to differentiate them by choosing different configs.

P.S. There's also an issue on vscode repo - looks like it's hard to support choosing a custom config from their side: microsoft/vscode#12463

[Timer]

I agree right now overly strict TypeScript configurations can cause a bit of headache during development. Typically, this is solved by a separate tsconfig.prod.json you run over your code base using tsc w/ noEmit.

As for now, we're going to start working to make TypeScript errors as unobtrusive as possible before we hand out the knobs to completely disable this integration.

Please bear with us! 🙏

[gothy]

Even trying to disable this compiler error by setting "noUnusedLocals": false doesn't help, it looks like some tsconfig.json setting are ignored 🤔

[fabb]

i'd like to exclude test.tsx? files from next compilation, but need to include the files in tsconfig.json so i get proper autocomplete in VSCode. any ideas how to solve this?

[eric-burel]

When using an src folder, an alternative could be to exclude *.tests.ts, *.stories.ts etc. in the main config, but create a new tsconfig.json that reinclude them, in src/tsconfig.json.
This config would only be targeted at VS code.

However I am not sure if it's right. More broadly I lack the knowledge on how to check precisely which files are included in which build to debug that. The interactions between VS Code, Next, and TypeScript are unclear to the end user.

[mulholo]

When using an src folder, an alternative could be to exclude *.tests.ts, *.stories.ts etc. in the main config, but create a new tsconfig.json that reinclude them, in src/tsconfig.json.

I followed this approach and it worked really well for me. Thanks!

[danawoodman]

Is there any plans to support this in the near future?

This is causing me a lot of headaches because Next is trying to compile my test setup files in my root which means I have to have my test dependencies in dependencies because Heroku barfs 🤮 on next build when deploying 😢

[eric-burel]

Funky bug I had today:
Since Jest tests are part of the tsconfig, test is a valid global variable. I mistakenly misnamed a variable isTest and used wrongly it as test => the build was fine locally, but failed on the server where I don't install Jest at all.

[karlhorky]

Now that TypeScript 4.1 is out with compilerOptions.jsx values of both react-jsx and react-jsxdev, maybe this idea of two separate configs has an additional reason to exist?

I suppose as suggested in facebook/create-react-app#10025, it would be possible to default to react-jsxdev in the config file, and then in the next build script, mutate that to react-jsx...?

My question, which I also posed in the CRA issue above, is whether there are large, useful differences in functionality between react-jsxdev and react-jsx.