Question

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?

Answer 1

You can use a pre-commit hook, which is a script that runs before you commit your changes to the repository. You can use husky to set up a pre-commit hook that checks for any JavaScript files in your staged files and prevents you from committing them. For example, using husky, you can add a script like this to your package.json file:

{
  "husky": {
    "hooks": {
      "pre-commit": "git diff --cached --name-only | grep -E  \.(js|jsx)$  && echo  Error: JavaScript files (.js/.jsx) are not allowed in this repository.  && exit 1 || true"
    }
  }
}

Of course, for this, you need to install husky package as dev dependency.

For example:

npm i husky -D

Answer 2

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

友情链接