Closed devinrhode2 closed 1 year ago
Ok this is even crazier than I was expecting...
typescript folks need to take a break
I think a simpler solution is to provide a starting typesync config file that ignores a few high profile tools like babel and eslint.
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
I didn’t even realize one could do that this way 😄
A blurb in the readme for ignoring tool packages makes sense.
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;"
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.
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 ofbabel.config.js
file, I've seennext.config.js
files have types applied like so:/** @type {import('next').NextConfig} */
Presumably, same thing could be done with babel configs:
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:
.babelrc
? Do we even care about this?.ts
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?
babel.config.js
(or maybe.babelrc.js
) file/** @type {import('@types/babel__core').MainConfigFileType} */
right above themodule.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