DEV Community: gulnur

I Want to Become an Open Source Contributor, But I Don't Know Where to Start

gulnur — Wed, 15 Jul 2026 10:18:42 +0000

Cover image is from-> Image by magnific

I've always admired people who contribute to open source.

Every time I use a library, read its documentation, or find a solution on GitHub, I've realized that someone took the time to build it, improve it, and share it with the community.

The truth is, I honestly don't know where to begin. 🧐

It's not that I'm afraid of writing code. I've spent years building web applications, fixing bugs, and learning new technologies as a software engineer. But open source feels like a different world.

Questions keep coming to mind:

How do people choose their first project?
Is improving documentation enough for a first contribution?
How do you avoid breaking someone else's project?
What's the proper etiquette when opening an issue or a pull request?
How do I figure out what a project actually needs?

The more I think about it, the easier it becomes to postpone taking that first step. So instead of waiting until I have everything figured out, I've decided to make this one of my goals.

My Open Source 101 plan 📅

Find a project I actually use.
Read its documentation, issues, and commit history.
Look for beginner-friendly issues.
Submit my first pull request, even if it's just a documentation improvement.
Learn from the review process instead of trying to be perfect.

I know my first contribution won't be groundbreaking 😃, and that's okay. Every experienced open source contributor started with a first pull request, right?

If you've been contributing to open source for a while, I'd love to hear your advice.

What was the first project you contributed to, and what helped you get started?

And if you're in the same position as me, maybe this is the sign that we should both stop waiting and start contributing..

Note: My goal is to submit my first open source pull request before the end of this month. I'll come back and share what I learned whether it succeeds or fails.

Why My Angular 21 Upgrade Failed 👀

gulnur — Thu, 09 Jul 2026 09:48:39 +0000

I believe Angular upgrades have become much smoother these days. Most of the time, a simple ng updateis enough to move to the latest version.

Instead, I spent hours chasing errors that looked completely unrelated to the real problem 😭

After upgrading the project to Angular 21, I started seeing errors like these:

Cannot find module '@angular/material/chips'
Cannot find module '@angular/material/dialog'

Then another one appeared:

Error: The current version of "@angular/build" supports Angular ^19...
but detected Angular version 21.x instead.

At first, it looked like Angular Material wasn't installed correctly but i think the actual issue was a version mismatch inside the project.

Some packages had already been upgraded to Angular 21:

@angular/core
@angular/common
@angular/material

But the build system was still using:

@angular-devkit/build-angular@19

Since Angular's build tools are tightly coupled with the framework version, the compiler started producing misleading errors.

The build pipeline was the problem.

The Commands That Helped

I used these commands:

npm ls @angular-devkit/build-angular

npm explain @angular-devkit/build-angular

They showed that my project was still resolving Angular 19's build package. That was the clue I needed and than I verified that every Angular package was using the same major version.

Then I cleaned the project completely:

rm -rf node_modules
rm package-lock.json
npm cache clean --force
npm install

It takes time usually.(and I did it several times cause Im failed 😃)

Finally, I confirmed that all Angular packages were aligned before building again.

the Last Sunset

gulnur — Sun, 21 Jun 2026 09:03:11 +0000

This is a submission for the June Solstice Game Jam

What I Built

The Last Sunset is a browser-based narrative survival game inspired by the June Solstice theme.

The concept explores a world where time itself is collapsing. Each day becomes shorter than the last, and the sun is gradually fading from existence. The player controls an autonomous AI archival unit tasked with preserving fragments of human civilization before the final sunset.

Instead of traditional combat or scoring systems, the game focuses on knowledge preservation. Players collect “data capsules” containing remnants of human history such as scientific discoveries, space exploration missions, and digital archives.

As the game progresses, the environment becomes increasingly unstable, reflecting the collapse of both time and memory.

Video Demo

canva.com

Codepen:

Code

The project is built using:

Vanilla JavaScript (no frameworks)
HTML5 Canvas API for rendering
Custom game loop with time scaling
Procedural particle system for feedback effects
Dynamic day/night cycle with a shrinking sun mechanic

🔗 GitHub Repository:

Gulnur-Altan / theLastSunset

A narrative survival game built for the June Solstice Game Jam

🌅 The Last Sunset

A small narrative browser game inspired by the June Solstice.

In a world where the sun is slowly fading away, you play as an AI archive unit collecting fragments of human knowledge before the final sunset.

🎮 Features

Dynamic day cycle
Shrinking sun mechanic
Knowledge capsule collection
Collapse Mode after Day 7
Multiple endings based on progress
Built with HTML5 Canvas and Vanilla JavaScript

🕹 Controls

Action	Key
Move Left	A
Move Right	D
Jump	Space

🚀 Run Locally

git clone https://github.com/yourusername/the-last-sunset.git
cd the-last-sunset

Start a local server:

python -m http.server

Then open:

http://localhost:8000

🛠 Tech Stack

HTML5
CSS3
JavaScript
Canvas API

🏆 Challenge

Created for the June Solstice Game Jam.

Preserve humanity's knowledge before the last sunset.

View on GitHub

Key systems include:

Collision detection (AABB)
Particle burst system for interactions
Screen shake and slow-motion effects
Narrative memory synthesis system
Collapse mode visual degradation system

How I Built It

I started with a simple canvas-based platformer and gradually evolved it into a narrative-driven experience.

The core design decision was to avoid traditional “win/lose” mechanics and instead focus on emergent storytelling through systems.

Key implementation steps:

Built a physics-based movement system (A/D + jump)
Added procedural spawning of “knowledge capsules”
Designed a dynamic time system where each day becomes shorter
Implemented a shrinking sun to visually represent entropy
Introduced a “collapse mode” after Day 7 where visual glitches and terminal corruption begin
Created a memory synthesis system that generates a final narrative based on collected data

To improve game feel, I added several “juice” effects:

Particle bursts on pickup
Camera shake on interaction
Slow-motion moment during collection
Terminal-style archival feedback

These small additions significantly improved immersion and emotional feedback.

Prize Category

🧠 Best Ode to Alan Turing

The game’s narrative structure is inspired by computational memory and symbolic reconstruction of information — concepts closely aligned with Alan Turing’s legacy.

The “memory synthesis system” at the end of the game reconstructs a final narrative from fragmented data, similar to how an intelligent system interprets incomplete information.

🤖 Best Google AI Usage

The concept of emergent storytelling and memory reconstruction was designed with AI-inspired thinking in mind.

The final system behaves like a simplified symbolic model that reconstructs meaning from partial inputs, similar to how modern AI systems generate coherent narratives from fragmented context.

What Happens When Companies Stop Hiring Juniors?

gulnur — Thu, 18 Jun 2026 07:35:04 +0000

cover image is from->https://wingassistant.com/blog/junior-developer-101/

Over the last few months, I've noticed a common trend in job postings: everyone seems to be looking for mid-level and senior engineers. On the surface, this makes sense. Experienced developers require less onboarding, can contribute faster, and often need less supervision.

But what happens when an industry collectively reduces junior hiring?

The first consequence may be that new graduates and career changers struggle to enter the field. Companies ask for experience, but gaining experience is difficult without a first opportunity. Also, I have many friends who have been searching for jobs for months despite actively improving their skills.

Today's seniors were once juniors. If fewer junior developers enter the industry now, the future talent pipeline becomes smaller. Eventually, companies may find themselves competing for the same limited pool of experienced engineers.

There is also a knowledge transfer problem. Strong engineering cultures are built when experienced developers mentor less experienced ones. If junior hiring continues to decline, opportunities for mentorship and long-term team development may decrease as well.

AI tools may change how entry-level work is performed, but they do not eliminate the need for new engineers. Every senior engineer started somewhere.

Perhaps companies should be asking, "How can we help junior developers become productive faster?"

Because an industry that stops investing in beginners may eventually run short of experts.

Related writings:

Why AI is Replacing Junior Developers and How Mid-Level...

AI tools like Claude Code are displacing junior developers by handling boilerplate and basic tasks, while simultaneously flooding codebases with unoptimized,...

daily.dev

Why You Should Hire a Junior Developer

Wondering whether a junior developer is the best fit for your software needs? What are a junior dev's responsibilities Read our article to help you decide!

wingassistant.com

Anthropic released new FREE AI courses

gulnur — Tue, 09 Jun 2026 13:57:01 +0000

Anthropic has released FREE courses on its Skills platform. You can now earn free certificates in Skills, MCP, Subagents, Claude Code, and other AI-related topics directly from Anthropic.

I've already enrolled and will be reviewing the courses over the next few days.

If you'd like to check them out:
https://anthropic.skilljar.com/

You can read:
https://app.daily.dev/posts/anthropic-just-released-new-free-ai-courses-vhinyl3gs

Image source:
https://media.daily.dev/image/upload/s--jdHyrLn2--/f_auto/v1780938861/posts/vHinyL3Gs?_a=BAMAMiWQ0

Giving a Forgotten Side Project a Second Chance

gulnur — Sun, 07 Jun 2026 10:30:21 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Deploy Friday ☄️

Deploy Friday is a small browser game inspired by the chaos of software development and Scrum teams. Players must survive a sprint by completing tasks, handling production incidents, and managing their stress level.

Built with:

HTML
CSS
Vanilla JavaScript

No frameworks or external dependencies. The game is powered by a few simple state variables:

let stress = 0;
let score = 0;
let sprintTime = 60;
let gameEnded = false;

Tasks are generated dynamically and random incidents keep the sprint unpredictable. If stress reaches 100%, the sprint fails.

Demo

gulnur-altan.github.io

The Comeback Story

This project started as a Scrum Quiz application with multiple-choice questions and score tracking. Although it worked, I lost interest and never finished it🥲

When I found this challenge, I revisited the project and realized it didn't need more quiz questions maybe it needed a new idea.

Instead of finishing the quiz, I transformed it into Deploy Friday, a sprint survival game inspired by real developer experiences such as production incidents, urgent meetings, and Friday deployments.

My Experience with GitHub Copilot

GitHub Copilot helped me generate repetitive UI code, prototype gameplay ideas, and refactor JavaScript more quickly.

The biggest benefit was shortening the gap between having an idea and testing it in the browser, allowing me to focus on the game itself rather than boilerplate code.

This challenge reminded me that sometimes unfinished projects don't need more features,they may need a fresh direction 🧐

All GitHub Copilot plans are now on usage-based billing

gulnur — Thu, 04 Jun 2026 08:20:57 +0000

GitHub officially switched to a usage-based billing model a few days ago. The era of unlimited $10 fixed fees is over 🥲

Recently, GitHub Copilot started introducing more detailed usage-based concepts around premium requests, model access, and AI consumption. Instead of treating all AI interactions equally, the platform is moving closer to a metered model where advanced workflows consume measurable resources.

I guess some features like code completions remain exempt from credit consumption

You can also use this link for the preview your price:
https://copilot-billing-preview.github.com/

This shift makes sense technically.Modern AI coding assistants are no longer simple autocomplete systems. They now:

generate large codebases,
review pull requests,
run agentic workflows,
analyze repositories,
reason across multiple files,
and interact with increasingly expensive frontier models.

Those operations require significant compute power.

The interesting part is that this starts to make AI tooling look less like traditional software subscriptions and more like cloud infrastructure pricing.

Developers are already familiar with this pattern:

storage usage,
API rate limits,
serverless execution time,
bandwidth consumption,
GPU compute.

AI coding assistants may simply be joining that list.

I think this also changes how developers will use these tools. Instead of blindly prompting large models for everything, we may start seeing:

smarter model selection,
lightweight workflows,
hybrid local/cloud setups,
and more attention to AI cost optimization.

In a way, “prompt efficiency” could become similar to cloud cost optimization in DevOps.

The bigger takeaway is probably this:

The industry is moving from “AI as a novelty feature” to “AI as infrastructure”. And infrastructure is rarely unlimited.

You can visit: https://github.blog/news-insights/company-news/changes-to-github-copilot-individual-plans/

Why Engineers Wear Hoodies While Social Media Sells Perfection

gulnur — Fri, 22 May 2026 10:09:31 +0000

cover image is from->Image by catalyststuff on Magnific

This is not a technical post, but something I’ve been thinking about lately.
On one side, many scientists, engineers, startup founders, and developers live surprisingly simple lives. You see people at companies like Google, OpenAI, or research labs wearing the same hoodie every day, using old backpacks, drinking plain coffee, and focusing deeply on their work.

On the other side, social media constantly tells young people that they need more:
more skincare,
more fashion trends,
more luxury cafés,
more “must have” products,
more aesthetics,
more shopping hauls,
more routines.

Personally, I find this culture difficult to relate to. The less you consume the less you need. Especially on platforms driven by influencers, life is no longer presented as something to experience. It becomes something to perform.

And the contrast is hard to ignore.

I sometimes feel that scientists, researchers, and professors are no longer cultural role models for younger generations.

Many highly intelligent and productive people simplify their lives to protect their attention.
Meanwhile, algorithms encourage everyone else to consume endlessly.

Simplicity Is Not Laziness

There is a reason many developers and scientists dress simply.

People like Steve Jobs, Mark Zuckerberg, and many engineers in Silicon Valley became known for repetitive, minimal clothing styles.

Not because they could not afford more. Because reducing unnecessary decisions saves mental energy.

When your brain is focused on building products, solving problems, writing code, researching medicine, or designing systems, appearance becomes less important than clarity.

Simplicity creates focus.

A quiet room.
A basic outfit.
A clean workspace.
A smaller circle.
Less noise.

image is from->Image by freepik

For many builders, minimalism is not a fashion statement.
It is an optimization strategy.

The Influencer Economy Profits From Insecurity

Social media works differently.

Influencer culture often depends on creating dissatisfaction:
your outfit is outdated,
your body is imperfect,
your lifestyle is boring,
your room needs redesigning,
your skin needs fixing,
your morning routine is wrong.

The business model is simple:
make people feel incomplete,
then sell them the solution(!)

Sometimes the pressure is different depending on gender.

Many young women are pushed toward beauty products, fashion trends, and appearance focused consumption from a very early age through social media and advertising.

Meanwhile, many men are pushed toward status symbols, gadgets, cars, or financial success.

Both are forms of consumer pressure. And algorithms reward this behavior because insecurity drives engagement.

The result is a generation constantly comparing themselves to curated lifestyles that are often unrealistic, filtered, sponsored, or financially unsustainable.

Consumption Has Become an Identity

Years ago, people bought products because they needed them. Now many people buy products to build an online identity.

Coffee becomes content.
Books become decoration.
Travel becomes proof.
Gyms become aesthetics.
Even productivity becomes performance.

Sometimes people are no longer asking:
“Do I need this?”

They ask:
“Would this look good online?”

Builders Often Think Long-Term

One thing I notice about many developers, engineers, and technical people is that they often prioritize long-term freedom over short-term appearance.

Instead of spending constantly to impress strangers online, they invest time into skills:

coding
research
writing
building products
learning systems
creating businesses

I believe the reward is slower.
But usually more real.

While social media trends change every month, deep skills compound for years.

Maybe Simplicity Is Becoming Rebellious Again

In a world trying to monetize attention every second, simplicity almost feels rebellious.

Wearing basic clothes.
Ignoring trends.
Using things longer.
Reading instead of scrolling.
Building instead of performing.

None of these things look exciting on social media.
But they might create a calmer and more meaningful life.

And maybe that is why so many builders quietly choose simplicity.
I think Im going to wear my hoodie until it falls apart.

“Simplicity is prerequisite for reliability.”
― Edsger W. Dijkstra

Understanding B2B SaaS Products as a Developer

gulnur — Fri, 15 May 2026 17:08:28 +0000

Cover image is from->https://www.flaticon.com/free-icons/saas

When I first started software development, I mostly focused on technologies:

Angular vs React
Java vs Go
SQL vs NoSQL
Docker, Kubernetes, APIs...

But after some time, I realized something important:

A lot of engineering decisions actually come from the product model itself.

Especially the difference between:

B2B
B2C
SaaS products

Understanding these concepts changes how you think about architecture, UX, scaling, integrations, and even deployment strategies.

So here’s a simple explanation from a developer perspective.

What is B2B?

B2B means: Business to Business

A company builds software for other companies.

Examples:

Slack
Jira
Salesforce
GitHub Enterprise
Gitlab Enterprise
Storytelling/analytics/CRM platforms (I am using some of them on daily basis)

In B2B products:

Customers are companies
Sales cycles are longer
Integrations matter a lot
Reliability is critical
Documentation and APIs are very important

this usually means:

Authentication systems
Role management
Enterprise integrations
Audit logs
SDKs
Multi-tenant architecture
Scalability
Security compliance

A B2B customer might have:

thousands of employees
millions of requests
strict uptime requirements

So engineering expectations are usually higher around stability and maintainability.

What is B2C?

B2C means: Business to Consumer

A company builds software directly for end users.

Examples:

Instagram
TikTok
Spotify
Netflix
Duolingo

In B2C products:

User experience is everything
Fast onboarding matters
Viral growth matters
UI/UX decisions are critical
Engagement and retention are key metrics

this often means focusing on:

performance
animations
recommendation systems
personalization
mobile experience
A/B testing
analytics

A small UI change can affect millions of users instantly.

What Does SaaS Mean?

SaaS stands for: Software as a Service

Instead of installing software locally, users access it through the cloud.It is a cloud-based software delivery model basically.

Examples:

Notion
Figma
GitHub
Linear
PostHog

Most modern startups today are SaaS companies.

Typical SaaS characteristics:

subscription model
cloud infrastructure
continuous updates
web-based access
recurring revenue

SaaS usually involves:

cloud-native systems
APIs
observability
CI/CD
distributed systems
monitoring
scalability

B2B SaaS vs B2C SaaS

This is where things get interesting. Both can be SaaS products, but engineering priorities change significantly.

B2B SaaS

Examples:

Salesforce
Atlassian
HubSpot

Engineering priorities:

integrations
reliability
permissions
dashboards
reporting
enterprise security
API quality

Success metric:
“Can businesses depend on this product every day?”

B2C SaaS

Examples:

Spotify
Netflix
Canva

Engineering priorities:

engagement
UX
personalization
recommendation algorithms
responsiveness
growth metrics

Success metric:
“Do users keep coming back?”

Why This Matters

As developers, we sometimes focus only on code quality.

But product type affects:

architecture decisions
infrastructure
scaling strategy
frontend complexity
deployment frequency
observability
even hiring decisions

For example:

A B2B SDK product may prioritize:

documentation
API stability
backward compatibility

A B2C social app may prioritize:

realtime features
experimentation
recommendation systems
engagement analytics

Different products create different engineering cultures.

Overall,learning technologies is important.

However,I believe understanding:

how products make money
who the users are
what problems businesses are solving

can make you a stronger developer

PostHog Custom Surveys: Beyond the Default UI

gulnur — Wed, 13 May 2026 07:57:03 +0000

PostHog provides a powerful analytics and experimentation platform, including built-in surveys for collecting user feedback. However, in real-world applications especially dashboards, internal tools, or B2B SaaS products the default survey UI is not always flexible enough.

In this article, I’ll walk through how I built a fully custom in-app survey UI on top of PostHog, while still using PostHog as the data and analytics layer.

This approach allowed me to keep full control over UX, layout, and behavior without introducing an additional backend or feedback system.

Why Go Beyond the Default Survey UI?

PostHog’s built-in surveys are great for quick setups, but I ran into a few limitations and I would like to edit the pop-up.

Limited control over positioning and layout

UI didn’t fully match with my applicaiton

Needed a lightweight, non-intrusive CES-style survey

Wanted tighter control over when and how the survey appears

Instead of replacing PostHog, I decided to treat it as a survey engine, not a UI framework.

Architecture

The idea is simple:

PostHog Survey
↓
onSurveysLoaded()
↓
getActiveMatchingSurveys()
↓
Custom Angular UI
↓
posthog.capture()

PostHog decides when a survey should be shown.
My application decides how it should look and behave.

Listening for Active Surveys

One important lesson: calling getActiveMatchingSurveys() too early often returns an empty array.

The correct approach is to wait for surveys to finish loading.

posthog.onSurveysLoaded(() => {
  posthog.getActiveMatchingSurveys((surveys) => {
    if (!surveys.length) return;

    const survey = surveys[0];
    this.surveyId = survey.id;
    this.questionId = survey.questions[0]?.id;
    this.question = survey.questions[0]?.question;
  });
});

Why this matters

Without onSurveysLoaded, surveys may not be available yet

Ad blockers or strict CSP rules can silently block surveys

Defensive checks prevent runtime errors

Building a Lightweight Custom UI

Rather than using modals or full-screen components, I chose a small fixed-position card with a basic css, that feels native.

.survey {
  position: fixed;
  bottom: 24px;
  right: 24px;
  max-width: 360px;
  padding: 16px;
  border-radius: 4px;
  border: 1px solid #ddd;
  background: #fff;
  font-size: 14px;
  z-index: 1000;
}

@media (max-width: 768px) {
  .survey {
    right: 16px;
    left: 16px;
  }
}

Design goals:

Minimal color usage
Mobile-friendly
Easy to dismiss

No disruption to the main workflow

Submitting Survey Responses

When the user submits a response, the survey is sent back to PostHog as a custom event.

posthog.capture('custom_survey_submitted', {
  survey_id: this.surveyId,
  question_id: this.questionId,
  value: selectedValue,
});

When Does a Custom Survey Make Sense?

Custom surveys are especially useful when:

You need design-system consistency

You’re building internal tools or admin panels

Feedback should feel contextual, not disruptive

You want analytics-grade data, not just form responses

PostHog excels as the decision and data layer,custom UI lets your product own the experience.

If you want, you can visit posthog website,they doing lots of great things.

Useful Links:
https://posthog.com/
https://github.com/PostHog/posthog
https://www.npmjs.com/package/posthog-js

Getting Started with Playwright E2E Testing

gulnur — Mon, 11 May 2026 13:40:56 +0000

Modern web applications need more than unit tests.

You also need to test real user flows such as:

Login
Checkout
Form submissions
Navigation

This is where Playwright becomes useful.

Why Playwright?

Playwright is a modern E2E testing framework developed by Microsoft.

Main advantages:

Cross-browser support
Auto waiting
Parallel test execution
Fast and reliable
Works with Chromium, Firefox, and WebKit
Installation

npm init playwright@latest

Simple Login Test

import { test, expect } from '@playwright/test';

test('user can login', async ({ page }) => {
  await page.goto('https://example.com/login');

  await page.fill('#email', 'test@example.com');
  await page.fill('#password', '123456');

  await page.click('button[type="submit"]');

  await expect(page).toHaveURL('/dashboard');
});

One of the Best Features: Auto Waiting

Playwright automatically waits for elements to become available before interacting with them.

await page.click('#submit');

In many cases, you don't need manual waits anymore.

Running Tests

npx playwright test

You can also run Playwright in UI mode:

npx playwright test --ui

I personally use this mode a lot while debugging and fixing my tests.

If you are building production-grade frontend applications, adding E2E testing to your workflow is worth considering.

Before Cloning a GitHub Repository: How to Check If It’s Safe

gulnur — Thu, 07 May 2026 12:38:23 +0000

As developers, we clone GitHub repositories almost every day.

Sometimes to learn a new framework, sometimes to test an open-source project, and sometimes simply because a repository looks interesting.

But here’s the problem:

Running unknown code on your machine can be risky.
(I’ve also heard many stories on LinkedIn about this kind of scam. Yes, this is a real scam, and some people share these repositories with candidates who believe they are going through a legitimate interview process)

A simple npm install, pip install, or shell script may execute malicious commands, download hidden binaries, expose environment variables, or even install crypto miners.

Open source is powerful, but “public” does not automatically mean “safe”.

In this writing, we’ll go through a practical checklist to evaluate whether a GitHub repository looks trustworthy before running it locally.

1. Check the Repository Owner

Before cloning anything, look at who owns the repository.

Ask yourself:

Is this a real developer or organization?
Does the account have activity history?
Are there multiple repositories?
Do contributors look legitimate?

A repository created yesterday with zero history and copied documentation is already a warning sign.

Fake repositories often imitate popular projects using similar names.

Example:

react-official-tools
nextjs-fast-build
docker-helper-pro

Some malicious repositories are intentionally named to look trustworthy.

2. Inspect the Commit History

A healthy repository usually has:

consistent commits
meaningful commit messages
multiple contributors
issue discussions
pull requests

Be cautious if you see:

one huge initial commit
random generated commit names
no development history
suspicious binary file uploads

Check:

git log --oneline

If everything appeared suddenly in a single commit, inspect more carefully.

3. Read the Installation Instructions Carefully

One of the biggest mistakes developers make is blindly copying commands from README files.

Especially commands like:

curl something.sh | bash

or:

sudo chmod -R 777 /

Never execute commands you do not fully understand.

Look for:

external downloads
hidden shell scripts
encoded commands
unnecessary sudo usage

4. Check package.json or Build Scripts

For JavaScript projects, inspect the scripts section before running npm install.

Example:

"scripts": {
  "postinstall": "node install.js"
}

postinstall scripts execute automatically during installation.

Check for:

obfuscated JavaScript
external downloads
crypto mining packages
suspicious environment variable access

Useful commands:

cat package.json

grep -i "postinstall" package.json

5. Review Dependencies

Sometimes the repository itself is clean, but dependencies are malicious.

Attackers occasionally publish packages with names very similar to popular libraries.

Example:

expresss
reeact
lodas

This is called typo-squatting.

Use tools like:

npm audit

pip-audit

go mod verify

Also check:

outdated dependencies
abandoned packages
unknown private registries

6. Avoid Running Unknown Code on Your Main Machine

This is probably the most important habit.

If you are testing an unknown project:

use Docker
use a virtual machine
use a separate development environment

Example:

docker run -it --rm node:20 bash

This isolates the environment and reduces risk.

Running random repositories directly on your personal machine is not a great idea.

7. Look at the Security Tab

GitHub provides useful security information.

Check for:

security policies
dependency alerts
vulnerability reports
signed commits

Repositories with active maintenance and security practices are usually more trustworthy.

8. Be Extra Careful With AI-Generated Repositories

AI tools make it easier than ever to generate fake or low-quality projects.

Some repositories now contain:

copied README files
auto-generated code
hidden malicious payloads
fake stars or fake engagement

A professional-looking README does not guarantee safety.

Always inspect the actual code.

Open source software is one of the best parts of modern development.

But developers should approach unknown repositories with the same caution used when downloading software from the internet.

A few minutes of inspection can prevent:

credential leaks
malware infections
exposed SSH keys
compromised development environments

Before running code, take a moment to verify what you are actually installing.