facebook / jscodeshift

A JavaScript codemod toolkit.
https://jscodeshift.com
MIT License
9.26k stars 477 forks source link

Help: adding a line of comment `@ts-expect-error IGNORE TEMP` above all lines in files with type errors #548

Closed legendkong closed 1 year ago

legendkong commented 1 year ago

Hey guys, cracking my head over this and will appreciate any help I can get. I have a huge folder with many files containing type errors (over 600) due to migration from React 16 to React 18. As a team, we have decided to temporarily comment out all these type errors by writing a script (codmod) using jscodeshift, and then resolving them one by one in the future. Ideally, the codemod should insert a // @ts-expect-error IGNORE TEMP above the line of error just like the image below where initially, there was an error for children.

Screenshot 2023-03-07 at 11 29 44 AM

How do I parse through all my files and detect the lines with type error(s) so that I can insert the comment?

ElonVolo commented 1 year ago

Detecting the type errors is something that's the purview of Typescript, as opposed to jscodeshift. You'd want to run typescript and then get the output of each line with an error, and maybe save that output into a json file so you have maximum flexibility feeding like numbers identifying those areas to custom tools, tools like jscodeshift. You can scan the AST for line numbers corresponding to type errors/liens in the JSON you output and prepend a comment node right before the code for that line.

(Warning: unsolicited, strong opinions ahead)

However...if I were in your situation I'd first look into whether someone's already written a codemod/migration scripy that does all of the react 16-18 migration.

Aside from that, if aliens were going to blow up the Earth if I didn't migrate your codebase to React 18, I'd just turn type-checking off (maybe for entire files or even whole project) until I mitigated all that technical debt, which I'd do in a separate branch backed by technical debt stories in JIRA. The technical debt migration branch would only get merged in when migration's complete. Each sprint,the PO would allocate some portion of story points to people working on the migration branch.

Honestly, this situation with your codebase sounds like something that has to be an organizational initiative with real story points put behind it and critical stakeholders who will stand behind it. Incrementalism in something in a codebase that's extensive and intertwined, IME, leads to a huge messes and endlessly-open PR's.

legendkong commented 1 year ago

@ElonVolo Thanks for taking the time to reply to this.

You can scan the AST for line numbers corresponding to type errors/liens in the JSON you output and prepend a comment node right before the code for that line.

Got it. Sounds about right.

Honestly, this situation with your codebase sounds like something that has to be an organizational initiative with real story points put behind it and critical stakeholders who will stand behind it.

Agreed. We're still considering the options available for this issue, and I think we're leaning more towards ignoring/expecting-error for the type errors, and then slowly resolving them one by one in the future just like what you've mentioned here.

Thanks for this, will close this issue!