"But It Works on My Machine! 🤷‍♂️ How package-lock.json Saves the Day"

Ashish Jha — Mon, 03 Mar 2025 10:51:16 +0000

BASICS

Ever had a project work perfectly on your machine, but when your friend (or worse, your CI/CD pipeline) runs it, everything falls apart like a Jenga tower? Yeah, blame dependencies.

In a Node.js project, package.json is like your shopping list—it says, "I need React, but I’m cool with any version above 18.2.0.(denoted by ^)" Meanwhile, package-lock.json is the receipt—it says, "You got React 18.2.3 from this exact store, and don’t even think about changing it!" It locks the exact versions of not just your dependencies, but also their dependencies’ dependencies (yep, it's dependencies all the way down). This means that when someone else runs npm install, they get the exact same versions as you—no surprise updates, no weird bugs, no "But it works on my machine!" moments.

Now, let’s break down exactly why package-lock.json is the hero we never knew we needed.

package.json

Purpose: Defines the project's dependencies, metadata, scripts, and configurations.

Contains:

Project name, version, and description.
Scripts (npm start, npm test, etc.).
Dependencies (dependencies, devDependencies, peerDependencies, etc.).
Version ranges for dependencies, like:

"dependencies": {
  "react": "^18.2.0",
  "axios": "~1.4.0"
}

Versioning:
Uses semantic versioning (SemVer) ranges:

"^1.2.3" → Allows updates up to <2.0.0 (i.e., 1.x.x updates).
"~1.2.3" → Allows updates up to <1.3.0 (i.e., 1.2.x updates).
"1.2.3" → Locks the dependency to exactly 1.2.3.

package-lock.json

Purpose: Ensures deterministic installs by locking exact versions of dependencies and all nested dependencies.

Contains:

Exact versions of direct and transitive (nested) dependencies.
Resolved URLs from where dependencies were installed.
Integrity checksums for security and verification.

Why Do We Need Both?

package.json:

Defines what dependencies your project needs.
Allows flexibility for minor updates.
Useful for open-source projects to let users install compatible versions.

package-lock.json

Ensures that everyone working on the project installs the exact same versions.
Prevents "works on my machine" problems.
Improves performance by caching resolved dependency versions.

What Happens If You Delete package-lock.json?

Running npm install will generate a new package-lock.json file with potentially different versions for dependencies, especially if they were specified with version ranges in package.json.

Should You Commit package-lock.json?

✅ Yes, especially for teams and production apps, to ensure consistency across environments.
🚫 No, if you're building a reusable package/library (e.g., an npm package), because the consumer should decide which versions to use.

NOTE:
If you're using yarn, it creates a yarn.lock file instead of package-lock.json, serving the same purpose.

And that’s the magic of package-lock.json—keeping your project safe from the dreaded “But it works on my machine!” chaos. Hopefully, now you see why this little file is your best friend when it comes to dependency management.

Got questions? Confused about something? Or just want to rant about npm breaking your build at the worst possible time? Drop your thoughts in the comments! I’d love to hear them (and maybe cry with you over dependency nightmares). 😆👇

Understanding and Preventing XSS Attacks: A Frontend Developer’s Guide

Ashish Jha — Sat, 01 Mar 2025 14:44:11 +0000

Cross-Site Scripting (XSS) is one of the most prevalent security vulnerabilities in web applications. As front-end developers, understanding how XSS attacks work and how to mitigate them is crucial for building secure applications.

By the end, you'll not only understand XSS inside out but also gain practical strategies to secure your applications—without the usual jargon overload. Stick with me, and you'll never have to second-guess your app's security again!

1. What is XSS?

XSS (Cross-Site Scripting) is a security vulnerability that allows attackers to inject malicious JavaScript code into a web application. This code executes in the context of the victim’s browser, enabling attackers to steal sensitive data, hijack sessions, or deface websites.

How Does XSS Work?
XSS occurs when user input is not properly sanitized and is directly rendered into the DOM. For example, consider a simple web application that greets users by name:

<input type="text" id="name" placeholder="Enter your name">
<button onclick="greet()">Submit</button>
<p id="output"></p>

<script>
  function greet() {
    const name = document.getElementById('name').value;
    document.getElementById('output').innerHTML = `Hello, ${name}!`;
  }
</script>

If a user enters <script>alert('XSS!');</script> as their name, the browser will execute the script, resulting in an alert box. This is a classic example of Reflected XSS.

2. Types of XSS

There are three main types of XSS attacks:

1. Reflected XSS

Description: The malicious script is reflected off a web server, such as in a search result or error message.
Example: A user enters a malicious script into a search bar, and the server returns the script as part of the response.
Impact: The script executes in the victim’s browser, often leading to session hijacking or data theft.

2. Stored XSS

Description: The malicious script is permanently stored on the server (e.g., in a database) and served to users who access the affected page.
Example: A user posts a comment containing a malicious script on a blog. Every visitor who views the comment executes the script.
Impact: Affects all users who view the compromised content, making it more dangerous than Reflected XSS.

3. DOM-based XSS

Description: The vulnerability exists entirely in the client-side code. User input is directly manipulated into the DOM without proper sanitization.
Example: A URL parameter is used to dynamically update the page content.

const userInput = new URLSearchParams(window.location.search).get('input');
document.getElementById('output').innerHTML = userInput;

If the URL contains input=<script>alert('XSS!');</script>, the script executes.

Impact: Similar to Reflected XSS but does not involve server-side processing.

3. Preventing XSS Attacks

General Best Practices

Sanitize User Input: Always validate and sanitize user input on both the client and server sides.
Escape Output: Escape special characters in user input before rendering it in the DOM.
Use Secure Libraries: Leverage libraries like DOMPurify to sanitize HTML.

Preventing XSS in Vanilla JavaScript

Escape HTML Characters: Replace special characters like <, >, &, ", and ' with their HTML entities.

function escapeHTML(str) {
  return str.replace(/&/g, '&amp;')
            .replace(/</g, '&lt;')
            .replace(/>/g, '&gt;')
            .replace(/"/g, '&quot;')
            .replace(/'/g, '&#039;');
}

const userInput = `<script>alert('XSS!');</script>`;
document.getElementById('output').innerHTML = escapeHTML(userInput);

Avoid innerHTML: Use innerText or textContent instead of innerHTML to prevent script execution.

document.getElementById('output').textContent = userInput;

Preventing XSS in React and Modern Frameworks

Use JSX Safely: React automatically escapes content in JSX, preventing most XSS attacks.

const userInput = `<script>alert('XSS!');</script>`;
return <div>{userInput}</div>; // Safe, React escapes the content

Dangerously Set Inner HTML: If you must use dangerouslySetInnerHTML, sanitize the input first.

import DOMPurify from 'dompurify';

const userInput = `<script>alert('XSS!');</script>`;
const cleanInput = DOMPurify.sanitize(userInput);

return <div dangerouslySetInnerHTML={{ __html: cleanInput }} />;

Avoid Direct DOM Manipulation: Use React’s state and props instead of directly manipulating the DOM.

Conclusion

XSS is a powerful and dangerous vulnerability, but it can be mitigated with proper precautions. As a frontend developer, your role is critical in ensuring user input is safely handled and rendered. By following best practices like input sanitization, escaping output, and leveraging secure libraries, you can build robust and secure applications.

Remember: XSS is just JavaScript injection, and it’s up to you to stop it from becoming a threat. Stay vigilant, and happy coding! 🚀

Further Reading:
https://www.youtube.com/watch?v=EoaDgUgS6QA

DEV Community: Ashish Jha