My company has been working to convert all of our JavaScript (.js
or .jsx
) files into TypeScript (.ts
& .tsx
). The problem is, we’re a fairly large company and there will be a continuous stream of .js
and .jsx
files sneaking into the codebase unless we lint against them specifically. Also, ideally there would be a way to force a bypass of this for circumstances in which we need .js
or .jsx
files.
We use ESLint, typescript-eslint, and prettier, is there an easy way to set a rule banning plain JavaScript files from being committed? It seems like this should be really easy but I can’t find any information on it – all searches seem to turn up results on ignoring certain filetypes, rather than banning them.
I’m considering skipping using a linter altogether and running something like
# Prevent committing .js and .jsx files
git diff --cached --name-only | grep -E '.jsx?$' > /dev/null
if [[ $? == 0 ]]; then
echo "Error: JavaScript files (.js/.jsx) are not allowed in this repository."
exit 1
in a pre-commit hook, or making an entirely new rule in a custom plugin, and then hooking that up to our repository. In either case I feel like others must have solved this problem by now, is there an easier existing solution?
2
Answers
You can use a
pre-commit
hook, which is a script that runs before you commit your changes to the repository. You can usehusky
to set up apre-commit
hook that checks for any JavaScript files in your staged files and prevents you from committing them. For example, usinghusky
, you can add a script like this to yourpackage.json
file:Of course, for this, you need to install husky package as dev dependency.
For example:
Instead of a pre-commit hook, I would basically use git’s ignore file to hide/ignore all files with the js extension, with the current list of existing (known) files as exceptions. As each file is then converted, the committer can keep trimming down the exception list in your
.gitignore
file. This way, you will also have a quantifiable/finite goal that you are marching towards and it can provide a sense of completion.Imo, this is better in the sense that its language agnostic, but my answer is specific to git. Ofc, you can do the same for other source control management softwares like cvs, mercurial, bazaar, svn, etc