If we need to handle CORS within Express, we can simply write the following (we’ll assume you’ve also added express to your packages)
Now our usual Express code with the addition of CORS support
import express from "express";
import cors from "cors";
const app = express();
const server = http.createServer(app);
app.use(cors());
const port = 4000;
server.listen(port,
() => console.log(`Server on port ${port}`)
);
I noticed, a while back, how github has some fabulous tooling which runs across our repos. on our maven and node packages (and probably more). I wanted to have something similar hooked into my CI/CD pipeline for my React and Node projects.
There’s several solutions, but the one I am talking about here is retire.js. There’s several ways to run retire.js, I’m going to concentrate on running it from the command line.
So first off you need to install retire.js, either globally or in my case I’m going to add to the dev packages
You may also need to run the following if you get an error saying it’s missing
Now we can simply run yarn retire from our project’s folder. Without any arguments this will run both JavaScript and NPM checks.
In my case I got three vulnerabilities listed for jquery, but as they’re primarily used as part of webpack dev server (in my case) I don’t really need/want them reported as they’re outside of my hands and hopefully webpack server will update them in forthcoming releases, so I want to ignore these for now. To ignore such reports create a file named .retireignore.json (other variants exists of this file), now add the following
[
{
"component": "jquery",
"justification": "Used by webpack dev server"
}
]
In this example I’ve ignored all issues around jquery, but that may be too course and mean we do not catch other possible issues around jquery usage, so we can instead add identifiers and list specific issues to ignore, for example
[
{
"component": "jquery",
"identifiers": { "issue": "2432" },
"justification": "CORS issue, we only worth within the intranet"
}
]
Note: from what I could tell (although not 100% on this) you can only ignore single issues, even though the use of the plural “identifiers”. I would assume if you’re going to ignore multiple issues then it’s probable you would just ignore all issues for a specific version of a package.
We can ignore specific versions of packages using
[
{
"component": "jquery",
"version": "3.3.1",
"justification": "Used by webpack dev server"
}
]
You’ve got your JavaScript or TypeScript project, you’ve added eslint and set-up all the rules and you’re happily coding, committing and pushing changes to GIT, the only problem is you’re ignoring your lint results or worse still, not even running lint prior to committing changes.
Enter, Husky and link-staged.
Note: I’m describing using Husky on a Windows machine, installation may vary depending on OS.
Let’s add them to our project using
Now, within package.json (after the scripts section is as good a place as any) add the following
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.{js,jsx,ts,tsx}": [
"eslint"
],
"*.{js,jsx,ts,tsx,json}": [
"prettier --write",
"git add"
]
},
Note: Husky also supports it’s own configuration files .huskyrc, .huskyrc.json or .huskyrc.js
Husky adds the ability to run applications/code on various GIT hooks. The most useful, from the perspective of this post, is the pre-commit hook as we want to stop any commits until all lint failures are fixed.
In the configuration, above, we call lint-staged when GIT commit is executed. The commit hook will run husky and husky will then run lint-staged with the previously defined configuration.
Lint-staged runs the linter (in this configuration, eslint) over our various staged files and also executes prettier against the same files (as well as JSON) adding these changes.
With these two tools set-up, we no longer have the option to forget to run the linter or ignore it as it’s now part of the commit process. Ofcourse we only fail a commit on staged files, so in situations where we add these applications to an existing project we’re not force to fix all linting issues until we attempt to actually stage and commit the files.
I’ve merged or rebased and don’t want to fix everything
Obviously all’s great until you find old code that may need to be merged or we rebase and now have staged files which fail the lint process and we don’t want to fix them.
In such cases, simple set the environment variable HUSKY_SKIP_HOOKS to true or 1 prior to running a git command, for example
HUSKY_SKIP_HOOKS=1 git rebase ...
Beware the formatting infinite fix then fail circle
One thing to be aware of, if you’re using prettier, as per the configuration above, make sure your eslint and prettier adhere to the same rules – initially I found that eslint would complain about some formatting (I cannot recall which at the moment) so would fail the commit, upon changing the offending code to pass eslint, the prettier command ran as part of lint-staged and changed the format back, meaning it then failed the lint and would fail the commit again.
However, running prettier and having it write changes in obviously a great way to (at least try) to enforce consistency on our code format.