Only install @babel packages if certain conditions are met

[devinrhode2]

I did some analysis on what the @types/babel__core and @types/babel__preset-env packages actually are.

If someone does not even have a babel config file in their project - installing these is definitely a waste of disk and network resources

I'm not sure if typescript will do anything with .babelrc (json) files, but certainly, there's a case for installing these @types/babel__FOO packages, if someone has some sort of babel.config.js file, I've seen next.config.js files have types applied like so: /** @type {import('next').NextConfig} */

Presumably, same thing could be done with babel configs:

/** @type {import('@types/babel__core').MainConfigFileType} */

So, I don't now all the conditions in which @babel types should be installed, but these are maybe the two ends of the spectrum.

Open questions:

1. Can typescript provide type checking for .babelrc? Do we even care about this?
2. What are all the valid ways to define a javascript babel config file? _{Since we can have type checking on javascript files, I assume we should not concern ourselves with supporting non-standard .ts config files}

• Should we try and use cosmic-config to find all the babel js config files?

====

I think given the simple fact that the babel types packages only help type-check babel config files, and I'm guessing most people are not really worried very much about that, maybe we special-case @babel packages, until we have something more sophisticated that makes these packages actually useful?

• One thing we could do:

1. Normalize babel config to a babel.config.js (or maybe .babelrc.js) file
2. Add /** @type {import('@types/babel__core').MainConfigFileType} */ right above the module.exports in that file. We could have an alternate approach for ESM - but I think it'd be better to normalize to either cjs or esm - and I think cjs is the safer+easier choice here.

TL;DR: installing @babel @types is currently a waste

[devinrhode2]

Ok this is even crazier than I was expecting...

typescript folks need to take a break

[jeffijoe]

I think a simpler solution is to provide a starting typesync config file that ignores a few high profile tools like babel and eslint.

[devinrhode2]

I think whichever solution we go with, we'll at least want a little blurb in the readme mentioning e.g. how to type check eslintrc.js

[jeffijoe]

I didn’t even realize one could do that this way 😄

A blurb in the readme for ignoring tool packages makes sense.

[devinrhode2]

Well I think everyone is going to be curious about these types.. so "yes you can ignore them, but if you want you can also use them like so;"

[devinrhode2]

I realized there's another dimension here.

We can use this /** @type {FOO} */ syntax to add types in javascript files.

At least for our TS version, 3.9.10, I was not getting an error here:

/** @type {Record<string, string>} */
module.exports = {
  "foo": 123
}

Instead... I had to do this to get errors:

/** @type {Record<string, string>} */
const fooConfig {
  "foo": 123
}
module.exports = fooConfig

Also, need to ensure that yarn tsc or yarn your-type-check-command ensures no type errors slip into main or master branch.

Also, here's my tsconfig.json:

{
  "compilerOptions": {
    "module": "esnext",
    "target": "es2017",
    "lib": ["es5", "es6", "ESNext", "dom"],
    "jsx": "preserve",
    "allowJs": true,
    "checkJs": true,
    "skipLibCheck": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true
  },
  "typeRoots": ["./src/types", "./node_modules/@types"],
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".*rc.js"],
  "exclude": ["node_modules"]
}

Diff:

And, my working yarn type-check command used in CI:

"type-check": "tsc --pretty --noEmit",

It's hard to say if .ts config files are the future. (related: https://github.com/vercel/next.js/issues/5318) There's even a "kernel" of deno that is even in plain javascript. I'd expect this /** @type {FOO} */ syntax could be quite popular for 1-4 years, and possibly stay around for 15-20 years, when/if typescript passes the torch to a "native" javascript type system. After 4yrs I'm betting we'll be using .ts for all configs.