Add ESLint rule to enforce extensions for imports
Summary:
In D6692, I updated all imports to include .js extensions to satisfy Webpack 5 and Node.js 19. To make sure we don't regress on this, in this diff I introduce an ESLint rule for enforcing extensions for all imports.
To make this diff easier to review, I'll highlight relevant changes with inline comments.
As part of this, the ESLint rule identified some places that the codemod script in D6692 didn't catch. They include:
- Places where we use CommonJS require instead of import
- Imports from within packages. In D6692, I updated places that just needed a .js extension (eg. lodash/fp/merge.js). But in some cases it was more complicated... I either couldn't find a file at all (eg. electron/main), or found that there was a package.json inside the directory instead of an index.js. I ended up adding eslint-disable macros to hide the cases that were hard to update, or following the package.json indirection to find the real file in the easier cases
- Note that I could've configured the ESLint rule with ignorePackages instead of always, but I opted not to do this after testing it against my Webpack 5 branch and finding that Webpack wanted imports from within packages to be fully qualifed
Depends on D6693
Test Plan:
- I ran web, landing, keyserver, and native all together and made sure everything still worked
- I tested web against my Webpack 5 branch (coming soon) and noted if any errors appeared or went away regarding places where imports were changed. Usually errors went away, but in some cases I had to test a couple times to make sure the imports worked correctly
- In places where I actually changed something, my inline comments sometimes mention ways I tested them
Reviewers: atul, tomek
Reviewed By: atul
Subscribers: michal
Differential Revision: https://phab.comm.dev/D6694