fix(dev): Add placeholder tsconfigs for tests

[lobsterkatie]

It is well-documented (1, 2, 3, 4, 5, 6) that VSCode doesn't support setups like ours, where multiple tsconfig files coexist in a single directory. Strangely, though, it is only recently that this has become a problem, with VSCode at random intervals forgetting that it's ever heard of expect or describe (because it's not seeing tsconfig.test.json, but taking a while to realize it).

There is an open issue tracking the addition of support for this, but it's been open for a long time, with little movement. In the meantime, this solves the problem by adding placeholder test/tsconfig.json files to each package, each pointing to its corresponding tsconfig.test.ts file. I went with this approach over simply moving and renaming the existing test tsconfigs because this allows us to stay consistent in having all flavors of tsconfig for a package live at the package root level, and provides an easy way to reverse this workaround, should VSCode ever fix the underlying problem.

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser - ES5 CDN Bundle (gzipped + minified)	19.36 KB (-3.88% 🔽)
@sentry/browser - ES5 CDN Bundle (minified)	60.05 KB (-7.07% 🔽)
@sentry/browser - ES6 CDN Bundle (gzipped + minified)	18.21 KB (-3.47% 🔽)
@sentry/browser - ES6 CDN Bundle (minified)	53.66 KB (-7.44% 🔽)
@sentry/browser - Webpack (gzipped + minified)	19.92 KB (-14.26% 🔽)
@sentry/browser - Webpack (minified)	63.12 KB (-22.76% 🔽)
@sentry/react - Webpack (gzipped + minified)	19.95 KB (-14.31% 🔽)
@sentry/nextjs Client - Webpack (gzipped + minified)	43.74 KB (-8.99% 🔽)
@sentry/browser + @sentry/tracing - ES5 CDN Bundle (gzipped + minified)	25.38 KB (-2.67% 🔽)
@sentry/browser + @sentry/tracing - ES6 CDN Bundle (gzipped + minified)	23.91 KB (-2.33% 🔽)

[lforst]

Looks good to me in the meanwhile, the only gripe I have with this change is, that it adds yet another tsconfig. Have you evaluated the following shuffling around of configs?:

[package]/tsconfig.test.json --> [package]/test/tsconfig.json (what you did here)
[package]/tsconfig.json --> [package]/src/tsconfig.json

Bonus:
- delete [package]/tsconfig.types.json and use [package]/src/tsconfig.json + cli options to generate types

Also, I would be in favor of moving the repo-root-level tsconfigs to a private package and importing them, not via a path but via node resolution. That seems the cleanest to me.

[AbhiPrasad]

Also, I would be in favor of moving the repo-root-level tsconfigs to a private package and importing them, not via a path but via node resolution. That seems the cleanest to me.

This works well because we can just put them in the @sentry-internal/typescript package.

[lforst]

I think we could merge this and make the tsconfig setup even cleaner later on

[lobsterkatie]

the only gripe I have with this change is, that it adds yet another tsconfig.

Yeah, I know... The annoying thing, and one of the reasons we have so many tsconfigs to begin with, is that any path we use (in include, for example), has to be relative to the tsconfig file location, so even packages which make no changes to the repo-level tsconfig have to have their own copy of tsconfig.json, tsconfig.test.json, etc.

It would be really nice if you could do it like eslint, and have one file containing all of the different options, each with their corresponding include. It's not supported by TS, of course, but I wonder if we could rig it up ourselves...

Have you evaluated the following shuffling around of configs?:

[package]/tsconfig.test.json --> [package]/test/tsconfig.json (what you did here)
[package]/tsconfig.json --> [package]/src/tsconfig.json

Bonus:
- delete [package]/tsconfig.types.json and use [package]/src/tsconfig.json + cli options to generate types

I'm not sure I understand how this winds you up with fewer files - you get rid of the types file but add one in src, so don't you come out even? As for types, I actually really don't want to do that, because then some of our TS config lives in files and some live on the command line in yarn scripts, which feels like a recipe for confusion. What we could do is have one main, package-level tsconfig, and shove the other tsconfigs for the package into a folder. Not sure that gets you much, though - you're trading three files for a file and a folder containing two files, so ultimately you only have one less thing at the package level.

Also, I would be in favor of moving the repo-root-level tsconfigs to a private package and importing them, not via a path but via node resolution. That seems the cleanest to me.

This works well because we can just put them in the @sentry-internal/typescript package.

Yeah, I think that's a fine idea, as long as we can get it to work with multiple tsconfigs. (Based on this comment and the one after it, I'm not sure if we'd have to do a hybrid package-name-file-name extends or what, but we can certainly try it out. I also don't know how it would work with, say, tsconfig.dev.json's include value - I guess we've have to throw a ../../ on the front? Anyway, can't hurt to play around with it.)

Before we do that, though, I think it's worth taking a step back and figuring out/deciding what the point of having both @sentry-internal/typescript and a repo-level tsconfig is. Right now we have both because that's how I found things and it didn't seem broken so I left it, but I'm not sure it's actually necessary.

I think we could merge this and make the tsconfig setup even cleaner later on

Yeah, I'm going to do that, just so VSCode can stop freaking out at us, and we can figure the rest out separately.

[lforst]

Mostly agree with you! Just wanna tie up an open thread here.

I'm not sure I understand how this winds you up with fewer files

In my proposition we would move tsconfig.test.json to test/tsconfig.json. Right now we're just adding test/tsconfig.json. Meaning it would allow us to have one less file.