2 Ways to Improve your Node.js Application
source link: https://dev.to/therealdakotal/2-ways-to-improve-your-nodejs-application-1830
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
2 Ways to Improve your Node.js Application
Use npm ci --production
. Thanks for coming to my ted talk. 🎉
Kinda kidding, but not really.
For demonstration purposes, lets define a sample package.json, omitting some of the less important stuff.
{
"name": "test project",
"version": 1.0.0,
"description": "Our sample project",
"dependencies": {
"first-dep": "1.0.0"
}
}
So let's say you've been hard at work on this "test project" all morning working with the "first-dep" library. Unfortunately for you, "first-dep" released a minor version the night before, going up to "1.1.0" and breaking one of the API's you use. You run your test suite locally and everything is as green as grass. You push your code and egads batman a bunch of tests are broken. You run your tests locally over and over again racking your brain for what's happening. So you push another change just to see and watch the integration environment break again. So as is common practice in Node, you delete your local dependencies, reinstall and boom. Tests are broken. Finally. Now you go to source control provider to look for what's changed and you see a single change in your package.json
- "first-dep": "1.0.0",
+ "first-dep": "1.1.0",
The dreaded stealth patch. After some investigation, you discover that in your testing setup you run npm install
. Causing the version to get modified in that environments package.json before it was changed in yours. Now you've come to a cross roads. Typically most updates your dependencies release don't directly affect your project and are fine to push through. But wait!
npm ci
stops this discussion dead in its tracks. Using ci over install in your build environments defends against this versioning mismatch.
(npm) will never write to package.json or any of the package-locks: installs are essentially frozen. source
This brings us to the first usage improvement
- Create highly reproducible builds of your dependencies
As long as you haven't specified dependency changes, there shouldn't be any in your automated environments.
What does this mean?
Typically, when you run the command npm install
, you will have your dependencies installed, as well as some of your dependency versions updated if there are updates available. This can lead to some hard to find issues when running in an automated environment, similar to the one above.
- Smaller production bundles
Going back to our example package.json. Lets say we want to add typescript to our workflow. First thing you'll want to do is npm install typescript
. Now our package.json looks something like,
"dependencies": {
"first-dep": "1.0.0",
"typescript": "^4.4.3"
}
But typescript isn't required to run our application. Typescript is a build tool. So even though we're only using it some of the time, it will be included in our node_modules every time. Irregardless of what command we use to set them up. To address this, we should pass the "-D" flag when installing packages that aren't required to run our application in production. So now our command should look like npm install -D typescript
. Looking at our revised package.json, you should see something like,
"dependencies": {
"first-dep": "1.0.0",
},
"devDependencies": {
"typescript": "^4.4.3"
}
Awesome! But... typescript still shows up in node_modules when you run npm ci
. So it's great that we've started dividing our dependencies up between production and development, but the default behavior of both install commands is to install all dependencies. So we've got one more piece to this puzzle and that is the --production
flag. This instructs npm that we want to ignore all of the packages listed in devDependencies.
So in short, if you're running your application in an automated environment (shared development servers, production, testing) make sure you setup your dependencies with the command npm ci --production
. And while you're working any time you install a dependency that is not directly required by your app, install it with the "-D" flag.
Sponsor me on Github
Like the article? Buy me a coffee!
Recommend
-
6
开源日报 开源日报第970期:《什么都有一点 water.css》 2020-12-04 115...
-
10
7 Ways to Improve Your Relationship — Without Telling Your PartnerYou have more control than you think.
-
5
Responses (2)
-
4
Developers are a particularly hard audience to capture with ads. Most of them know how digital advertising platforms work from a technical standpoint. As a result, they’re not particularly enthused when they find ads that don’t meet their sta...
-
7
3 Effective Ways To Improve Your Site’s Carbon Footprint To mark Earth Day 2021, we’re looking at the ways you can reduce your site’s carbon footprint, while boosting performance, user experience, and SEO. At the dawn of th...
-
6
javascript7 Ways to Improve Node.js Performance at ScaleAyooluwa Isaiah on Nov 24, 2021
-
5
javascript4 Ways to Minimize Your Dependencies in Node.jsDmitry Kudryavtsev on Aug 31, 2022
-
3
The number of hackers learning to use web applications and APIs to exploit data has increased rapidly. Yet Gartner predicts that by 2025, less than 50% of enterprise APIs will...
-
3
How to Improve Node.js Application Performance ...
-
7
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK