You ask an agent to add a rule to checkout. It opens CheckoutPage.tsx, then CheckoutButton.tsx, then checkout.css, because they all have "checkout" in the name, and after forty seconds of enthusiastic reading it writes a change in the wrong place. The actual logic was in validateOrder, which the agent never opened, because nobody named it checkoutValidation.

What gets me about this isn't the wrong edit. Wrong edits are normal; I make them too.

It's the confidence. A human who doesn't know where the logic lives asks, or hedges, or leaves a comment saying they weren't sure. An agent working from bad context does none of that. It produces something clean and plausible and completely misplaced, and hands it to you like it's finished. You can't debug uncertainty that was never expressed.

And the model wasn't the problem here. Retrieval was. The model answered the question it was given. Nobody gave it the right one.

In Part 1 I built a code graph over a TypeScript codebase: 2,795 nodes, 17,985 edges, reduced to an 873-symbol search index. This article is about pointing that graph at an agent, and what happened when I actually measured it.

Including the case where it made things worse. We'll get there.

Why "just give it the repo" doesn't work

Take a real task: add a minimum-order rule to checkout.

Search by name and you get CheckoutPage.tsx, CheckoutButton.tsx, checkoutSlice.ts, checkout.css, checkout.test.ts. Everything with the word in it, and almost nothing that matters.

What actually governs the behaviour looks like this:

CheckoutPage → calls → createOrder
createOrder  → calls → calculateOrderTotal
             → calls → validateOrder
validateOrder → used by → POST /orders, POST /order-preview

Not one of those names contains "checkout" past the first line.

The context you want isn't files with a matching name. It's the dependency neighbourhood around the behaviour you're changing, and those two sets overlap far less than feels reasonable.

This is the part I underestimated for a long time. I kept treating bad agent output as a model problem, because that's the framing everyone reaches for: better prompt, better model, more context. Meanwhile the agent was doing competent work on the wrong five files, over and over, and I was rewriting instructions at it.

This is what people have started calling context engineering, and it's where most of the leverage in agentic coding currently sits. Cursor, Claude Code, Aider's repo map and Sourcegraph all attack a version of it. A graph is just the version you can build yourself, tuned to conventions no generic tool knows about.

Retrieve a neighbourhood, not a directory

Start from a symbol and walk outward. One hop:

validateOrder
├── called by → createOrder
├── called by → previewOrder
├── calls → validateLineItems
└── calls → validateShippingRegion

Two hops:

createOrder  → used by → POST /orders
             → writes-state → checkout
previewOrder → used by → CheckoutSummary

Now assemble a packet: the target symbol, its callers, its dependencies, the routes affected, the state it touches, the nearby tests, and the architecture rules that apply.

Eight to fifteen files. Which is considerably more useful than 150 files chosen because they share a word, however impressive the token count looks.

The traversal itself is unglamorous:

function expand(graph: Graph, start: string, maxDepth = 2) {
  const visited = new Set([start]);
  let frontier = [start];

  for (let depth = 0; depth < maxDepth; depth++) {
    const next: string[] = [];
    for (const current of frontier) {
      for (const edge of neighbors(graph, current)) {
        const candidate = edge.from === current ? edge.to : edge.from;
        if (!visited.has(candidate)) {
          visited.add(candidate);
          next.push(candidate);
        }
      }
    }
    frontier = next;
  }

  return [...visited];
}

The next improvement isn't going deeper. It's being pickier about which edges you follow.

Weight your edges

For business logic, calls and writes-state matter enormously. Importing a CSS file or a shared <Button> matters approximately not at all. And yet an unweighted traversal treats them identically, which is how you end up with your design system in the context window.

const edgeWeights = {
  calls: 10,
  "writes-state": 10,
  "publishes-event": 9,
  "handles-route": 9,
  "reads-state": 8,
  renders: 5,
  imports: 2,
};

Obvious when written down. Retrieval systems fail to encode obvious things with impressive regularity.

Tell the agent what not to touch

Good retrieval isn't only about surfacing code. It's about surfacing boundaries.

Say your layering is UI → service → adapter → vendor SDK, and the agent proposes this:

// CheckoutPage.tsx
import paymentSdk from "payment-sdk";

A graph-aware check catches the new component → vendor SDK edge and rejects it before merge.

You could instead write "never import the SDK directly" in your instruction file and hope.

I've tried hoping. It works most of the time, which is somehow worse than failing outright. You stop checking, and then one Tuesday it doesn't, and the violation is already three commits deep. Prompts help. But an executable constraint has the notable advantage of not forgetting on a Tuesday.

// UI components cannot import repositories
const violations = graph.edges.filter(
  e => e.kind === "imports" && isComponent(e.from) && isRepository(e.to)
);

The cheapest rule to implement first: deprecated modules cannot gain new callers. Store a baseline count, fail if it grows. You may not get to delete the old module this quarter (you probably won't) but you can stop it spreading, and unlike most architecture rules it needs no classification logic whatsoever.

Blast radius, before the edit

An agent wants to change normalizeCustomer. The graph knows it has five direct callers, and that those callers hang off an HTTP route, a nightly import job, and two event consumers.

Target: normalizeCustomer

Direct callers:           5
Affected HTTP routes:     1
Affected background jobs: 2
Affected event consumers: 2
Nearby tests:            11

Risk indicators:
- high fan-in
- used by async worker
- crosses into the billing boundary

A crude score turns that into a ranking signal:

risk =
  directCallers * 2 +
  affectedRoutes * 4 +
  backgroundJobs * 4 +
  externalApis * 5 +
  stateWrites * 3;

Please don't turn this into a sacred number that gates your CI. The question it answers is which changes deserve extra care, not can I mathematically prove this line is dangerous. Software has never once agreed to be that cooperative.

Documentation is the other half

Some things the compiler simply cannot know.

If OrderPreviewService deliberately uses a cached price snapshot, because recalculating would make previews change after the customer approved them, no amount of static analysis recovers that reasoning. But the graph knows OrderPreviewService → calls → getPriceSnapshot, so when a task touches either symbol, that decision record can be pulled into context automatically.

Clean division of labour: the graph knows what exists and what connects; the docs explain why the weird parts are deliberate.

Keep the root doc a router

Your agent instruction file (AGENTS.md, CLAUDE.md, whatever your tool reads) should hold only what isn't derivable from the code, with a hard size limit. Mine is capped around 300 lines, which is about 6,200 tokens paid on every single session. When a section outgrows that, it's become a decision record.

Four things earn their place:

What does NOT belong where. A two-column table per folder: what belongs, and what doesn't. The negative column is the one that does the work. Every architecture doc tells you where things go; almost none tell you where things must not go, and a helper in the wrong folder is one the next person will never find, which is where duplication comes from in the first place.

A domain glossary. Business term → code term → API name. Without it, neither a new hire nor an agent can map a ticket onto a folder.

Confusing pairs, written from bugs that actually happened. In my codebase three different things are called some variant of "event," and two similarly-named entities are genuinely distinct objects that must never be merged. That section exists because both have already cost someone an afternoon.

Off-limits without discussion. Generated files, vendored code, anything external config might reference by name.

Don't start from a template. Start from your last five "why is it like that?" Slack threads and your last five review comments saying "we already have this." That's the content. It's already written; it's just scattered across conversations nobody can search.

Decision records that end in "Do not"

Not every decision deserves a record. The ones that do are the decisions a reasonable engineer will eventually try to simplify. Usually on a Friday, usually with good intentions.

So every ADR I write ends with a Do not section, phrased as the sentence that engineer would say to themselves:

# ADR: External API access stays behind adapters

## Context
The vendor SDK has unstable response shapes and inconsistent errors.

## Decision
Feature code calls typed adapter functions.

## Do not
Do not import the SDK directly inside a feature module,
even if your new feature only needs one endpoint.

That last section is the difference between a decision log and a guardrail. A normal ADR explains a choice to someone who reads it. A "Do not" line intercepts someone who was never going to read it, because it's the phrase they'll grep, or the phrase retrieval surfaces at the moment it matters.

Two rules keep this honest. ADRs are append-only. Supersede, never edit, so a record is either current or explicitly historical with no third state where it quietly disagrees with the code.

And now the embarrassing part

The second rule is that these documents rot, and a confidently wrong router is worse than none at all.

I can be specific about this, because when I re-ran my measurements I audited the docs against the code at the same time. Here's my own paperwork:

Every one of those was written by someone careful. I know, because it was me. I'd written the negative-space table and the append-only rule in the same sitting, feeling quite good about myself.

Nothing in my process caught any of it. There was no moment where the docs announced they'd gone wrong. They just sat there, confident and slightly false, for months.

The second row is the one that stings. A "not done yet" list advertising a gap that was closed months ago will send the next person off to rebuild something that already works. That isn't documentation sitting there being harmlessly stale. That's documentation actively wasting someone's afternoon.

Tie doc review to convention changes rather than the calendar, and audit the docs whenever you regenerate the graph. The graph is the only thing in your repo positioned to catch your prose lying.

Correct for the model's priors, too

One more failure mode, running in the opposite direction.

The first review my instruction file got flagged that the model kept adding memoization everywhere. The reviewer's diagnosis: its training data skews toward older React, where you had to. Newer versions handle much of it automatically.

That isn't the model lacking knowledge of my codebase. It's the model having too much knowledge, of the wrong vintage, applied with total confidence.

So an instruction file has two jobs. It encodes what's true about your repository, and it corrects what the model assumes about your framework. The second kind is easy to skip because it doesn't feel like documentation. It feels like arguing with a very self-assured junior. Write it down anyway:

## Version-specific: override your priors

- React 19: do not add useMemo/useCallback defensively.
  The compiler handles most of this. Memoize only with
  a measured reason.

Both kinds go stale, in opposite directions. Your code drifts from your docs. The model's assumptions drift from your framework. The router file sits between them and is the only thing watching either.

Diff the graph after the patch

Before: Feature → Service → Adapter → External API. After: same chain, plus a shiny new Feature → External API.

It compiles. The tests pass. Nothing is red. And an architectural boundary just moved.

The graph delta catches it:

Graph delta

+ CheckoutPage → calls → validateMinimumOrder
+ validateMinimumOrder → reads-state → pricingRules
- CheckoutPage → imports → legacyValidation

No new cross-layer imports.
No new dependency cycles.

Easier to review than a 600-line diff you're scrolling through at 5pm hoping the architecture reveals itself.

The general principle: check effects, not just generated text.

The whole loop, assembled

Put the retrieval half and the verification half together and you get something that looks less like "an AI writes code" and more like a pipeline with the model as one stage in it.

Steps one to four decide what the model is allowed to see. Steps six to eight check what it did with that. The agent itself only ever occupies step five, which is a considerably smaller share of the system than the marketing around agents would have you believe.

That framing is useful when something goes wrong, because it gives you somewhere specific to look. Bad output means either the packet was wrong or the model was wrong, and those live in different stages with different fixes.

So what does it actually save?

Time to stop asserting and measure.

I took six real discovery questions from my own codebase and ran each two ways. Through the symbol index, and through the exploration you do without one. Orient in the tree, grep a guess, grep again because the first guess missed, open files to confirm.

Real commands, real output, three repetitions, median reported.

Cells read with index / without.

81% less output for the model to read. 13 fewer tool calls.

The call count is what drives cost, because every call is a round trip that re-sends the whole accumulated conversation as input. Counting the final answer turn: 14 round trips against 27. Model those at current large-model pricing and the cost difference lands near 49%.

I swept the assumptions. Harness context from 4k to 80k tokens, output per turn from 200 to 4,000, latency from 3 to 20 seconds. It stays in a 48-51% band, because the result is driven by measured call counts rather than my guesses.

Now the caveats, which matter more than the percentage.

The without-index path is a modelled sequence, not an observed agent run. I wrote those commands based on what unaided search looks like here. A sharper agent might do the first task in two calls. A flailing one might take eight. The output volumes are real measurements of what those commands return. The baseline's shape is my judgement.

Token counts come from an estimator, not a token-counting endpoint. Call it ±10–15%. Applied identically to both sides, so the ratio holds even if absolutes drift.

And this prices discovery only. It doesn't price the thing the index mainly exists to prevent, which is an agent writing a second formatDate because it never found the first. That cost lands in review, or next sprint, or in a bug six months out. No single-session benchmark catches it.

Read 49% as a floor.

And when it makes things worse

Here's the number I suspect most posts like this quietly skip.

The instruction file loads every session whether anyone searches or not. 6,179 tokens, paid up front, every time. Against an average saving of about $0.076 per discovery task, it pays for itself within the first task of a session.

But the worst realistic case, with the instruction file loaded and the index never queried and the agent grepping anyway, comes out 9.1% more expensive than having no toolchain at all.

That's the downside bound. One avoided duplicate helper repays it many times over, so I'll take that trade all day. But if your own benchmark doesn't contain a number like this, you haven't finished measuring. You've finished marketing.

You may also find plain lexical search handles most of your tasks fine. Good. Use the graph where structure genuinely helps. The goal isn't to justify the elaborate thing you built.

Separate the retriever from the agent

This distinction does more work than anything else here.

When an agent makes a bad change: was the model weak, or did retrieval never surface the critical dependency? Different failures, different fixes. Track them together and every failure becomes "improve the prompt," including the ones caused by the agent never seeing the file.

On row three the model failed because the retriever never surfaced the shared rule. No amount of prompt engineering fixes that, though I'm sure someone has tried for a week.

Start with retrieval, not autonomy

If I were introducing this somewhere new I wouldn't begin with an agent editing production code.

Start here: developer asks a question → system finds relevant symbols → system shows the neighbourhood → developer picks what to read. Then: agent proposes context → developer reviews → agent proposes a patch. Automate further only after you've measured retrieval quality.

You get useful tooling immediately, and it survives the model layer changing underneath you, which it will, roughly every four months. The graph describes your repository, not somebody's API.

Quick answers

Is this just RAG for code? It's the retrieval half, with structure instead of embeddings. Chunk-and-embed finds text that reads similar. A graph finds code that's actually connected. Good systems use both.

How is this different from a repo map? A repo map is usually a flat summary handed over up front. A graph is queried per task, so context scopes to the change instead of the codebase.

Do I need this with Cursor or Claude Code? On a small codebase, probably not. Their retrieval is good. It starts paying off when your repo has conventions no generic tool knows, which is exactly what those framework-specific edges encode.

Does this work outside TypeScript? The concepts do. The implementation leans on the TypeScript type checker for cross-file resolution; you'd need an equivalent.

Building the graph itself

This article assumed the graph exists. For the implementation, covering Program, TypeChecker, symbol resolution, framework-specific edges and intent search, start with Part 1:

Build a TypeScript Code Graph with the Compiler API

The takeaway

The best use of a code graph in AI-assisted development isn't a prettier architecture diagram. It's controlling context.

What should the agent read. What should it not touch. What else might this change break. Which tests matter. Did this patch just move a boundary.

That's a retrieval and verification layer around the agent, and a far better foundation than "AI that can read the repo," which is not a strategy so much as a hope with a large context window.

The part I didn't expect: almost none of this work was about AI. Naming things findably, writing down which decisions are load-bearing, admitting where the docs had drifted. That's the same work that makes a codebase survivable for the humans in it. The agent just made the cost of skipping it visible, and put a number on it.

Which, honestly, is more than any of my previous attempts to care about documentation ever managed.

I'm Ashish Kr Jha, a software engineer. I build things in production and then have to live with them, which is the part that actually teaches you something. More at ashishkrjha.dev.

I have. More than once, in the same codebase. And once, on a helper I had written myself eight months earlier, under a name I no longer remembered choosing. That's the one that stayed with me.

There's a very particular flavour of embarrassment in that. Not "I didn't know the codebase," which is forgivable. More like finding out you've been introduced to yourself at a party.

And the genuinely infuriating part is that searching wouldn't have saved me. The function was there. It was called something I'd never have guessed in a hundred tries.

That's the problem this article is about. Not "how do I search my code" but something harder: how do I ask my codebase a question and get a real answer?

Three questions in particular:

1. Does this already exist?

2. Where does this code belong?

3. What will I break if I change it?

Grep can't answer any of them properly. But the TypeScript compiler can, and it's already sitting in your node_modules.

First, why grep runs out of road

Say you've got this import:

import { calculateOrderTotal as getCartValue } from "@/pricing";

const total = getCartValue(cart);

Now search for calculateOrderTotal. This file won't come up. The function is here, it's being called right now, but it's wearing a different name.

And even without the alias, @/pricing is almost certainly a barrel file re-exporting from somewhere else. Barrel files are wonderful for writing imports and actively hostile to everything that happens afterwards. The real declaration is two hops away from anything you typed.

Grep works on text. The TypeScript type checker works on meaning. Ask it what getCartValue refers to and it walks back through the alias, through the barrel, and hands you the actual declaration.

That difference is the whole article. Text search tells you a string appears in twelve files. The compiler tells you which symbols call which function. Only the second one is something you can safely refactor.

Why I actually built this

For a while I treated this as a personal failing. Learn the codebase better. Read more of it. Keep a list.

Then I watched a new engineer join and spend most of their first fortnight asking questions I couldn't answer cleanly either. Where does this belong, does something like this exist, what happens if I change this. I'd been there two years and I was guessing. Confidently, and often correctly, but guessing.

That's when it stopped feeling like a memory problem.

There's a threshold a codebase crosses where nobody holds it in their head anymore. Not the tech lead, not the person who wrote the first commit. Past that line you start making changes with a quiet undertone of I think this is fine, and you ship it, and mostly it is fine, and the times it isn't you find out from someone else's bug report.

I didn't want a better memory. I wanted to stop guessing.

What this looks like when it works

Before we build anything, here's the payoff:

$ node find-symbol.mjs "convert date to utc"

1. parseIsoTimestamp        dates/parseIsoTimestamp.ts
2. normalizeServerDate      dates/normalizeServerDate.ts
3. formatUtcDate            display/formatUtcDate.ts

I typed what I wanted. It found things named nothing like it, in about a third of a second, and I have never once had to remember what any of them were called.

Some numbers from the codebase I built it on, so you know the scale we're talking about:

The domain is anonymized and the examples below are generic, but every number is real.

Step 1: Ask TypeScript for a Program

A Program is TypeScript's view of your whole project: every file, resolved with the same config your app builds with.

import ts from "typescript";

const configPath = ts.findConfigFile("./", ts.sys.fileExists, "tsconfig.json");
if (!configPath) throw new Error("No tsconfig.json found");

const configFile = ts.readConfigFile(configPath, ts.sys.readFile);
const parsed = ts.parseJsonConfigFileContent(configFile.config, ts.sys, "./");

const program = ts.createProgram({
  rootNames: parsed.fileNames,
  options: parsed.options,
});

const checker = program.getTypeChecker();

Using the project's own tsconfig.json matters here. Your path aliases and allowJs settings need to match what actually compiles, or half your imports won't resolve.

Then walk the files:

for (const sourceFile of program.getSourceFiles()) {
  if (sourceFile.isDeclarationFile) continue;
  if (sourceFile.fileName.includes("node_modules")) continue;
  visit(sourceFile);
}

function visit(node: ts.Node) {
  if (ts.isFunctionDeclaration(node) && node.name) {
    addNode({
      id: `function:${node.name.text}`,
      kind: "function",
      name: node.name.text,
      file: node.getSourceFile().fileName,
    });
  }
  ts.forEachChild(node, visit);
}

You now have a list of every function in your project. Useful, but it's still just a list.

Tip: keep TypeScript AST Viewer open in a tab while you write this. Paste in a snippet, see exactly what node types come back. It'll save you an hour of guessing.

Step 2: Resolve symbols, not strings

Here's where it gets interesting. When you hit a call expression, ask the checker what's being called:

if (ts.isCallExpression(node)) {
  const symbol = checker.getSymbolAtLocation(node.expression);
}

But if that call came through an import, you've got an alias. A pointer, not the thing itself. So unwrap it:

function resolveSymbol(symbol: ts.Symbol | undefined) {
  if (!symbol) return undefined;
  if (symbol.flags & ts.SymbolFlags.Alias) {
    return checker.getAliasedSymbol(symbol);
  }
  return symbol;
}

That flag check isn't optional, and I found that out the way everyone does. getAliasedSymbol throws if you hand it something that isn't an alias. Not returns null, not returns the original. Throws. In a codebase with barrel files you'll hit both cases inside the same file, so guard it, or spend twenty minutes wondering why your build script dies on file three every single time.

Now record the relationship:

const resolved = resolveSymbol(symbol);
const declaration = resolved?.declarations?.[0];

if (declaration) {
  addEdge({
    from: currentSymbolId,
    to: symbolId(resolved, declaration),
    kind: "calls",
  });
}

You're now storing a link between two real declarations instead of two strings that happen to match. Everything else builds on this.

Step 3: Keep the data model boring

type NodeKind = "file" | "function" | "component" | "hook" | "state" | "package";

type EdgeKind =
  | "imports" | "calls" | "renders"
  | "uses-hook" | "reads-state" | "writes-state";

interface GraphNode {
  id: string;
  kind: NodeKind;
  name: string;
  file?: string;
}

interface GraphEdge {
  from: string;
  to: string;
  kind: EdgeKind;
}

Write it out as { "nodes": [], "edges": [] } and stop. I know "knowledge graph" sounds like it deserves something fancier, but plain JSON has one enormous advantage: it exists today, and you can query it with Array.prototype.filter.

Mine comes out at 5.5 MB. Gitignore it. We'll commit something much smaller in a bit.

Step 4: Teach it about your codebase

Everything so far is generic. If you stop here you've built a dependency graph, which dependency-cruiser and Madge already give you for free, and which you've just spent a weekend reinventing. Don't stop here.

The value comes from two functions you write yourself.

classifyFile(path) maps your folder conventions onto node kinds. src/hooks/ means hook, src/redux/slices/api/ means API client. Get this wrong and every query afterwards returns noise, because "show me the components that read this state" depends on the graph knowing what a component is.

detectFactoryKind(initializer) catches the things your framework creates through function calls. The AST just sees a const, so without help your graph is full of opaque constants where the interesting nodes should be. I detect createAsyncThunk, createSelector and createSlice. Yours might be defineStore, createMachine, or a DI registration.

Both are short, forty lines or so. They're also the difference between a generic import graph and a map of your system.

Now you can add edges nobody else could give you. When the walker sees this:

const cart = useAppSelector(state => state.cart);

it emits CheckoutPage → reads-state → cart. And when it sees a thunk:

export const refreshCart = createAsyncThunk("cart/refresh", async () => { ... });

it emits refreshCart → writes-state → cart.

Something I didn't expect. Those two state detectors produced 320 edges out of nearly 18,000, under 2% of the graph. They're also the ones people query. The compiler gives you thousands of edges for free; the handful you write yourself carry most of the weight.

The bug it found in its first week

I want to tell you about this one, because it's the moment the tool proved itself and it wasn't a feature.

My reads-state detector keys off the state shape, state.invoiceTemplates, plural. My writes-state detector keys off the name passed to createSlice({ name }), which turned out to be invoiceTemplate, singular.

Same slice. Two different names depending on which direction you asked.

My first reaction was that my detector was broken. My second, after ten minutes of checking, was the slightly cold realisation that it wasn't. The codebase had been carrying that inconsistency for years, and every one of us had walked past it.

Nobody had spotted it because no single file shows you both sides. You'd have to open the slice definition and a component that consumes it, at the same time, while specifically hunting for a mismatch that you have no reason to suspect exists. Nobody does that. Nobody has ever done that.

Expect a few of these. A graph that surfaces your naming inconsistencies is working correctly, even when the first thing it tells you is embarrassing.

Step 5: Make symbols searchable

A node gets far more useful once it carries more than a name:

{
  "id": "function:parseIsoTimestamp",
  "name": "parseIsoTimestamp",
  "kind": "function",
  "module": "dates",
  "summary": "Convert an ISO timestamp into UTC epoch milliseconds",
  "signature": "(value: string) => number"
}

The checker infers most of that for free, which is the nice part. You get a decent search index without asking anyone to maintain a catalog by hand.

One honest number before you get excited: in my index, 91% of symbols have a type signature and 24% have a written summary.

Signatures come from the compiler. Prose comes from humans. You can guess which one shows up reliably.

So if you want better search results cheaply, don't set out to document everything. Add doc comments to the shared helpers only, the forty things people keep re-implementing. That's where the return is.

Step 6: Search by intent

Now the search itself. The key idea is tokenization: toEpochMs and to_epoch_ms both break down into ["to", "epoch", "ms"]. That's what lets someone search for a thing they want and find a function named nothing like it.

This is the case grep structurally cannot handle. normalize_date and clean_timestamp share zero characters, so no regex will ever connect them, but both might be exactly what you meant.

The scorer is a weighted sum, and I'd encourage you to keep yours equally dull:

function scoreSymbol(symbol: SearchableSymbol, query: string) {
  const q = normalize(query);
  const name = normalize(symbol.name);
  const summary = normalize(symbol.summary ?? "");

  let score = 0;

  if (name === q) score += 1000;        // exact name
  if (name.includes(q)) score += 60;    // name substring
  if (summary.includes(q)) score += 25; // summary substring

  const queryTokens = tokenize(q);
  const nameTokens = new Set(tokenize(name));
  const summaryTokens = new Set(tokenize(summary));

  for (const token of queryTokens) {
    if (nameTokens.has(token)) score += 20;
    if (summaryTokens.has(token)) score += 6;
  }

  return score;
}

Module match adds 15, path match 10. The exact numbers barely matter. You'll tune them against your own repo within a day of using it.

Wrap it in a CLI with no dependencies:

node find-symbol.mjs "convert date to utc"
node find-symbol.mjs --kind component "loading spinner"
node find-symbol.mjs --module src/redux "thunk"

The part that makes it cheap

Here's the bit I like.

That 5.5 MB graph reduces down to a 717 KB index of 873 symbols. Run a token counter over it and it's roughly 248,000 tokens of structural information about the codebase. The full graph is closer to 1.9 million.

None of it is ever loaded into a context window. Not once.

A search reads it from disk, ranks it in about 300 milliseconds, and prints ten lines.

That ratio, two million tokens on disk and ten lines in the answer, is the entire argument for building structure instead of stuffing more files into a prompt. It's also why this works fine for humans who don't have a context window at all.

Commit the index, gitignore the graph. And pretty-print it rather than minifying. It changes on every edit and turns up in most diffs, so a reviewer is going to see it. A readable diff is the difference between "fine, whatever" and "can we please delete this thing." If merge conflicts get annoying, a merge=union gitattribute helps.

Do you need embeddings for this?

Not to start. Embedding search does help when the query and the symbol share no vocabulary at all, and that case is real.

But a lexical scorer is fast, local, explainable, free to run, and tunable in an afternoon. No vector database, no model dependency, no API key, no monthly bill for a service that indexes 873 functions.

Add embeddings later, once you've collected actual searches where the ranking failed. Otherwise you're solving a problem you haven't met yet, which is a considerably more expensive hobby than it sounds.

Same answer for graph databases. My entire query surface is graph.edges.filter(...) run through node -e. Reach for Neo4j when you need multi-repo traversal or interactive exploration, not because a diagram had arrows in it.

Keeping it honest

An index that was accurate three months ago is a historical document. Regenerate it in one of these places, best first:

1. Editor or agent post-edit hook. Freshest, zero ceremony, but only covers people using that tool

2. Pre-commit. This is the one that keeps it correct for the whole team

3. Manual, before searching. Costs 13 seconds

4. CI on merge. Fail if regenerating produces a diff

Whatever you do, don't put regeneration on a sprint cadence. It goes stale during the sprint, which is precisely when the duplicates get written. You'd be building a tool that is reliably most wrong at the exact moment anyone needs it.

My post-edit hook is 25 lines, and the most important line in it is this:

} catch {
  // Never disrupt the workflow. Swallow errors silently.
}

A background hook that can fail loudly will be switched off within a week, by you, irritably, mid-task, the third time it interrupts something. It either works invisibly or does nothing at all. Both outcomes are survivable. Popping up in someone's edit loop is not.

Where this doesn't help

Worth being upfront. The graph misses runtime dependency injection, string-based event names, dynamic imports, reflection, database relationships and external config.

The biggest gap is simpler: it only sees TypeScript. SQL, Python, templates, config files: all invisible, along with any coupling that runs through them. If a chunk of your logic lives in stored procedures, the graph is describing half your system while looking complete.

Treat it as a useful model, not an oracle.

Start smaller than this

You don't need everything above to get value. Here's the version that fits in a day:

1. Build a Program

2. Index files and exported symbols

3. Resolve imports and calls

4. Write classifyFile for your folders

5. Add one framework-specific edge, whichever coupling your team keeps asking about

6. Save as JSON, gitignore it, commit a reduced index

7. Add one command people run before writing shared code

Steps 1–4 are an afternoon. The rest is another one. On a 771-file tree the whole rebuild takes 13 seconds, so the loop while you're tuning detectors is quick.

Then watch what happens. Do people find existing helpers? Are fewer near-duplicate utilities landing? Which searches return junk?

The graph is only infrastructure. Its value comes entirely from the questions people actually ask it.

What I got out of it wasn't really the search command, in the end. It was that the codebase stopped feeling like something I was negotiating with. Changes I'd have approached carefully, I could now approach quickly, because I could see what was on the other side of them.

That's a small thing to say and a large thing to have.

Quick answers

Do I need a graph database? No. JSON and array filters go a long way.

How long does the build take? 13.1 seconds on 771 files. Fine on a save hook, too slow per keystroke.

Does this work for plain JavaScript? Partly. allowJs pulls .js files in, but without annotations the symbol resolution is much weaker.

Is this just an AST? No. An AST gives you syntax inside one file. The type checker resolves meaning across files, working out which declaration an identifier points at. That's the part that matters.

Should I use ts-morph instead? If you're writing codemods, yes, it's a much nicer API. I went with the raw Compiler API because the only import is typescript, which the project already had, so the script copies into another repo with no install step. That's the whole trade: a few hours of extra plumbing for zero new dependencies.

Next: handing this to an AI agent

Once your codebase is nodes and edges, search is only the first thing you can do with it. The same graph can decide what an agent should read before editing a function, which routes a refactor might touch, and whether a change just crossed an architecture boundary.

I measured that, including the case where it costs more than doing nothing:

Code Graphs for AI Coding Agents: Better Repository Context and Safer Refactoring

I'm Ashish Kr Jha, a software engineer. I build things in production and then have to live with them, which is the part that actually teaches you something. More at ashishkrjha.dev.

The CSS Box model is a box that wraps around every HTML element. The term "Box Model" is used when talking about design and Layout. It consists of few things: Margin, Padding, Borders, and the Actual content.

All the things in a box model give HTML a structure. We will discuss some of the options given to us for this model

Borders

Borders can be applied to most boxes in HTML. Borders have parameters such as

• border-width : This decidess what the width of the border will be

• border-style: This parameter helps us to determine the style of the border

• border-color: We can change the color of the border using this parameter

• border-radius: This is use to curve the edges and can help us to make the UI look more elegant or make rounded shapes.

  We can use the various options these parameters provide us. We can use these parameter on all four sides of the container. For more in-depth knowledge refer here

Margin

Margins are like their name suggests, consider the margins of your notebook. We try to keep things within the margins of the notebook. Similarly in CSS when we use margin it is applied on the outer side of the container. It can be use as

• margin: This applies the margin evenly on all four sides of the container

• margin-left : This applies the margin at the left side of the container

• margin-top : This applies the margin at the top side of the container

• margin-right This applies margin at the right side of the container

• margin-bottom: This applies the margin at the bottom side of the container

Warning: Overuse of Margin may lead to margin-collapse which messes up the entire flow of the layout.

It is best to avoid using margins in all places. Margins can affect the layout of other containers depending on where you use it. For more in-depth knowledge refer here

Padding

Padding is the gap inside, between the border and the content. It's like a cushion that separates the border and the content inside the container. Padding doesn't not impact anything outside of the container. It is essential to the layout.

Just like the margin, we can apply padding on all four sides of the container or just one side depending on the requirements of the UI. It can be applied as

• padding: This applies the padding evenly on all four sides of the container

• padding-left : This applies the padding at the left inner side of the container

• padding-top : This applies the margin at the top inner side of the container

• padding-right This applies margin at the right inner-side of the container

• padding-bottom: This applies the margin at the bottom inner-side of the container

For more in-depth knowledge refer here

Scope

The scope is the accessibility of variables, functions, and objects in some particular part of your code during runtime. In other words, scope determines the visibility of variables and other resources in areas of your code. Scopes are layered in a hierarchy, so the child has access to the parent's scope but not the other way around.

Think of it as the relationship between child and parent, the child can ask or take an ice cream or chocolate from the parents but not the other way around (I mean you can but...)

This example should give you a better understanding. Let's dive into the different types of scope in Js

What is a Global Scope?

Global scope is the default scope for running all the code in js and everything runs in this scope.

let globalVariable = 'test1'

function test() {
//some code
}

In the above example the globalVariable with the value of test1 is in global scope. In HTML the global scope refers to the window Object

• Module Scope: This is the scope of the modules in the code. You must have imported some modules if you have worked with any frameworks of Js

What is a Function Scope?

Function Scope is the scope created using a function

function test() {
let number = 45
console.log(number)// this will print the number 45 when the function is called
}
test()
console.log(number) //this will throw an error of the number is not defined

In the above example, you can see we cannot access the variables from outside the function if they are declared inside the function. But functions inside the function test() can access the variables of the parent function. Sometimes it is also referred to as Lexical scope.

How do let and const act in terms of scope?

There are let and const which work in block scope.

Block Scope It is a scope created by opening { and closing with }

{
    let num = 25
    const tea = 'tasty'
    console.log(num) // 25
    console.log(tea) // tasty
}
console.log(num) // num is not defined
console.log(tea) // tea is not defined

There is another keyword called var which has a function or global scope but it is not advisable to use this var keyword for declarations.

What is a scope chain?

Js engine uses a scope to find the exact location or accessibility of the variables and that particular process is called Scope chain. It means that one variable has a scope used by another variable or function having another scope.

Single Thread

Those of you who have been working with Js for a while would have come across the term called Single Thread. This term is just used to refer to a way javascript reads code which is one or single line at a time. Javascript is a language that runs one line of code at a time and waits until that line is complete and is ok and moves to the next line.

If the line needs time to execute it moves to the next line by default but to stop if from moving we can use async/await and wait until the current line is executed completely. We might have to do this because the results of the current line might be required for future lines of code. This happens because Javascript uses something called call stack which we will discuss in the next section

Call Stack

If you know the Data Structure of stack which follows LIFO, call stack is works just like that. However if you don't know the Data Structure Stack worry not, we got you covered.

Explain call stack.

Imagine a pile of books, a very tall pile of heavy books. If you try to get something at the bottom it will be very difficult and you might end up crashing the tower of those heavy books. So what do you do? You take the book on top and remove it and keep doing this until you reach your desired book. Same thing is happening in call stack. The term LIFO stands for Last In First Out, which simply means the book you kept last on the top of the pile needs to go out first

function A(){
    B()
    console.log(`I am Function A`)
}
function B(){
    C()
    console.log(`I am Function B`)
}
function C(){
    console.log(`I am function C`)
}
A()

Now in the above example you can see the function C ran first then function B and then finally function A. Image below explains this further.

The blocks in the above image are functions that were pushed into the call stack.

• First the program was scanned and it saw only function A is being called so it went to Function A
• In Function A it saw the call for Function B before the console.log could execute so it went to Function B and added it in the call stack, and from there to Function C and added it to the call stack.
• Entire functions are loaded and stacked on top on one another and so we execute the one at the top, In this case its Function C.
• After the execution of Function C, the next function in the call stack was Function B so it went ahead and executed the console.log there.
• And finally, it executed the last function remaining in the call stack which emptied the call stack.

Hoisting

JavaScript Hoisitng refers to the process by which the interpreter moves the declaration of functions, variables to the top of their scope before the code execute.

This allows Functions to be safely used before they are declared but variables and classes are hosted differently.

A general rule which helps me to track hoisting process is :

• Functions are scanned and stored in memory or made available for future use
• Variables are scanned and made undefined

Function Hoisting

A(5)
function A(num) {
    console.log('\n')
    console.log(num*num)
    console.log('\n')
}

As you can see in the example that the function A() is being called before the declaration. When the Javascript interpreter scanned the program it saw a function A() and it knew there is a function called A(). Without hoisting we would have to call the function after it is declared.

Variable Hoisting

According to the rule mentioned above Variables used before declaration will return undefined value

console.log(num)
var num  = 9
num = 8*8
console.log(num)

In the above example you can see the when we use variable before declaration it returns undefined. After which we declare it and give it a value of 9 and then change that value to 8*8 and console.log the value which returns 64 which is the result of 8*8.

This is example case but if we use let instead of var, it would throw an error on the first line saying num is not defined

Well, In programming it is just a collection of some similar or non-similar data. In Javascript, there is no restriction on array type. For example

int arr[] = { 10, 20, 30, 40};

the above array contains only numbers and is in the syntax of C++ language, as you can see the type int has been mentioned.

let arr = [ 'Cars', 4, true, ['this' ,'is' ,'subarray']]

However, In Javascript, we don't need the type declaration, which is a good or bad thing depending on the situation. The above example demonstrates the declaration of an array. In Programming arrays play a vital role. Javascript has provided us with multiple functions to make our life easier in development. In this Article we will be discussing the various aspects of the array functions in Javascript.

Declaration Using Constructor

We can declare array via above method called literal notation or constructor

const numbers = [1,2,3,4,5]

Another method to declare the array using the constructor

const  numbers = new Array(1,2,3,4,5)

We can also declare array length like

const numbers = new Array(5)

Static Array Methods

Array.from()

We can use static array methods to create a new arrays from some data we have. The syntax is Array.from()

Array from a String:

const name = 'mango'
console.log(Array.from(name))

Array after performing some operation: The Syntax is Array.from(array, function)

const arr = [1,2,3]
console.log(Array.from(arr, x => x*x))

Array.isArray()

This Array function checks if the given parameter is an array or not. It returns true if it is an array otherwise it returns false

const arr = [1,2,3];
const name = 'mango';
console.log(Array.isArray(arr));
console.log(Array.isArray(name));

Array.of()

The Array.of() method creates a new Array from the arguments given regardless of type.

console.log(Array.of('travel'));
console.log(Array.of(1,2,3));

Instance properties

Array.length

This is a widely used property that gives us the length of the array, array.length

const numbers = [1,2,3,4,5,6,7,'q','w','4',3]
console.log(numbers.length);

Instance Methods

Array.at()

This method returns array item at a given index, It also accepts negative integers as arguments and counts back from the last element. Array.at(), This is a fairly new method so it might not be available for you in your environment.

const numbers = [1,2,3,4,5,6,7,'q','w','4',3]
console.log(numbers.at(5));
console.log(numbers.at(-8));

Array.concat

This is a method which concatenates two different arrays into one array. array1.concat(array2)

const numbers = [1,2,3,4,5,6,7]
const numbers2 = ['q','w','4',3]
console.log(numbers.concat(numbers2))

Array.copyWithin()

The copyWithin() method copies part of an array to another location in the same array and returns it without modifying its length. It can take 3 arguments but atleast one argument must be present

array.copyWithin(target,start,end)

const numbers = [1,2,3,4,5,6,7,'q','w','4',3]
console.log(numbers.copyWithin(0,3,4))
console.log(numbers.copyWithin(0,3,7))

Array.entries()

This method gives us the index/value of the array elements. We can

const num = ['a','b','c','d']
for(const [index,element] of num.entries()){
    console.log(index,element)
}

Array.every()

This method checks if all the elements of the given array satisfies the condition. It returns true if all elements meet the condition otherwise false. We have taken a simple even number example

const isEven = (value) => value%2===0
const arr1 = [2,4,6,8]
const arr2 = [2,4,6,7]
console.log(arr1.every(isEven))
console.log(arr2.every(isEven))

Array.fill()

This is a method used to change array elements to a static value, it modifies the original array. General syntax

fill(value,startIndex,endIndex)

Here start Index and end index are optional, without these all elements will be replaced by the value. Also just like the .at() method we can use negative integers to start from the end of Array

console.log([1,2,3,5].fill(4));
console.log([1,2,3,5].fill(4,1))
console.log([1,2,3,5].fill(4,1,2))
console.log([1,2,3,5].fill(4,-3,-2))
console.log(Array(4).fill(4))

Array.filter()

This returns new array containing all the elements of the calling array for which the filter condition is true. It takes a callback function to check the condition.

const num = [1,2,3,4,5,6,7,8,9]
console.log(num.filter(ele => ele%2!==0))

Array.find() and Array.findLast()

The find() method returns the first element in array which satisfies the given condition. If no values found it returns undefined

The findLast() method returns the last element in array which satisfies the given condition instead of the first like in find(). If no values found it also returnsundefined`

//example contains only find() 
// findLast() also works same but returns last element.
const num = [1,2,3,4,5,6,7,8,9]
console.log(num.find(ele => ele>7))// check for number greater than 7

Array.findIndex() and Array.findLastIndex()

The findIndex() method returns the index of the first element in the array which satisfies the given condition. If no elements are found, it returns -1.

The findLastIndex() method returns the index of the last element in the array which satisfies the given condition. If no elements are found, it returns -1.

// example only contains of findIndex()
// findLastIndex() works the same but will return last element index.
const num = [1,2,3,4,5,8,6,7,9]
console.log(num.findIndex(ele => ele>7))//8 is at index 5
console.log(num.findIndex(ele => ele>10))// no element greater than 10

Array.flat()

This method creates a new array with all the sub-array elements added in order into it recursively up to the specified depth

const num = [1,2,3,4,[5,6,7],8,9]
console.log(num.flat())
const num2 = [1,2,3,4,[5,[[6]],7],8,9]
console.log(num2.flat(2))

Array.flatMap()

This method returns a new array which is formed according to the condition given in the callback function to each element of the array, and then flattens the result by one level.

const num = [1,2,3,4,[5,6,7],8,9]
console.log(num.flatMap((ele) => ele*2))
console.log(num.flatMap((ele) => ele))

Array.forEach()

This is a method for the array which works with each element and applies the function to each element.

const num = [1,2,3,4]
num.forEach(ele => console.log(ele*ele))

Array.includes()

This method checks for a certain value among the entries of the array and returns true if value is found else false

const num = [1,2,3,4]
console.log(num.includes(4))

Array.indexOf() and Array.lastIndexOf()

These two method returns the first and last index of the given element much like Array.findIndex() and Array.findLastIndex() method we saw earlier but unlike previous method, indexOf() allows us to decide which index to start the search from.

array.indexOf(searchElement)

array.indexOf(searchElement, fromIndex)

array.lastIndexOf(searchElement)

array.lastIndexOf(searchElement, fromIndex)

const num = [1,2,3,4,5,6,7,8,9,5,6,4,4,5,4]
console.log(num.indexOf(4,5))
console.log(num.lastIndexOf(4,num.length-2))

As you can see we started from the index 5 which holds the value 6 so we got the first 4 after 6 which was at the last index of 11. And for the lastIndexOf() we got num.length which is 15 and we started with 13th index and going reverse we got 4 at 12th index

Array.join()

This is a method used to join elements of array with a specific separated which is optional. The join() method creates and returns a new String by concatenating all the elements in an array. By default the separator is commas. If array has only one item it will remain unaffected.

arr.join() `arr.join('-')

const name = ['m','a','n','g','o']
console.log(name.join())
console.log(name.join('-'))
console.log(name.join('_'))

Array.map()

The map() method is another of the popular method people use. It creates new array and populates it with the results of calling the function on every element in the array

const numbers = [1,2,3,4,5,6,7]
const squaredNum = numbers.map(ele => ele*ele)
console.log(squaredNum)

Array.pop()

The pop() method removes the last element from an array and returns that element. This changes the original array's length

const numbers = [1,2,3,4,5,6,7]
console.log(`The Length before pop() is : ${numbers.length}`)
const popped = numbers.pop()
console.log(`The removed element : ${popped}`)
console.log(`The Array after Change ${numbers}`)
console.log(`The Length after pop() is : ${numbers.length}`)

Array.push()

The push() method adds one or more elements to end the array and returns the new length of the array

array.push(element1, element2,...,elementN)

const numbers = [1,2,3,4,5]
console.log(`The Length before push() is : ${numbers.length}`)
numbers.push(6,7,8)
console.log(`The Array after Change ${numbers}`)
console.log(`The Length after push() is : ${numbers.length}`)

Array.reduce()

The reduce() method executes a user-supplied "reducer" callback function on every element of the array. It works on each element step by step and in order. It does not change the original array

reduce((previousValue, currentValue, currentIndex, array) => { /* … */ } )

const numbers = [1,2,3,4,5]
console.log(numbers.reduce((ele, sum) => sum + ele))

Array.reverse()

The reverse() method reverse an array and returns the reference to same array, i.e it modifies the original array.

const numbers = [1,2,3,4,5]
console.log(numbers)
numbers.reverse()
console.log(numbers)

Array.shift()

This method removes the first element from the array and returns that element.

const numbers = [1,2,3,4,5,6,7]
console.log(`The Length before shift() is : ${numbers.length}`)
const shifted = numbers.shift()
console.log(`The removed element : ${shifted}`)
console.log(`The Array after Change ${numbers}`)
console.log(`The Length after shift() is : ${numbers.length}`)

Array.unshift()

The unshift() method adds one or more elements to the beginning the array instead at the last like push() and like push() it also changes the length.

const numbers = [1,2,3,4,5]
console.log(`The Length before unshift() is : ${numbers.length}`)
numbers.unshift(6,7,8)
console.log(`The Array after Change: ${numbers}`)
console.log(`The Length after unshift() is : ${numbers.length}`)

Array.slice()

The slice() method returns a copy of the portion of an array into new array object selected from start to end, where start and end are index of the items of the array. This method does not modified the original array

slice() slice(start) slcie(start,end)

const numbers = [1,2,3,4,5,6,7,8]
const sliced = numbers.slice(2,4)
console.log(numbers)
console.log(sliced)

Array.some()

The some() method tests a condition just like every() method but instead of matching the condition to all elements like it did in every(), in some() we just check if some elements match the condition, if some elements match then we return true If no element matches we return false

const isEven = (value) => value%2===0
const arr1 = [2,4,6,8]
const arr2 = [2,4,6,7]
const arr3 = [1,3,5,7]
console.log(arr1.some(isEven))
console.log(arr2.some(isEven))
console.log(arr3.some(isEven))

Array.sort()

This method sorts the array like the name suggests, it can sort both numbers and alphabets. We can also given a sorting condition. The default sorting condition is ascending.

const numbers = [1,2,6,7,8,34,5,21,5,2,1,0,12,45]
const alpha = ['r','t','v','f','a','b']
console.log(numbers.sort((a,b) => a-b))
console.log(alpha.sort())

Array.splice()

This method is used to change chunks of array and resize the array while changing the original array completely. We can delete the items or change their value using splice.

General Syntax

splice(start, deleteCount, item1, item2, itemN)

const numbers = [1,2,3,4,5,6,7]
const numbers1 = [1,2,3,4,5,6,7]
numbers.splice(2,3)
numbers1.splice(2,2,'a','4')
console.log(numbers)
console.log(numbers1)

Flexbox is a 1-D layout method for arranging items in rows or columns. Items expand to fill additional space or shrink to fit into smaller containers. Here we are going to discuss most of the things flexbox offers.

Flexbox offers the same set of things provided by CSS positioning but in a much more straightforward, flexible way. The main thing we keep in mind when using the flexbox is the container and its children.

Let's dive in

FlexBox Properties

This is without the flex property.

 .container{
    gap: 10px;
    display: flex;
}

By default, the flex-direction is row so all the elements inside the container are aligned in a row.

We can also add values to the flex-direction property

.container{
    gap: 10px;
    display: flex;
    flex-direction: column-reverse;
}

flex-direction has 4 property values we can use. What flex-direction does is, it changes the axis according to the property value we assign.

This is an image from MDN docs that gives us a better understanding of the axis. When we used flex-direction: column-reverse the main axis became from bottom-to-top and the direction matters for the upcoming property we will be exploring. The 4 values for flex-direction are given below:

• column: This value places the flex items vertically, from top to bottom.
• column-reverse: This value places the flex items vertically but from bottom to top.
• row: This value places the flex items horizontally, from left to right.
• row-reverse: This value places the flex items horizontally but from right to left

Flex-wrap

This happens when we have too many items clumped up together, to solve this issue we have flex-wrap because by default the flex items try to shrink and stay in the row/column so we need to add additional property to remove that skewed look.

.container{
    gap: 10px;
    display: flex;
    flex-wrap: wrap;
    border: 1px solid red;
}

flex-wrap has 3 property value

• wrap : This will be wrap flex items in multiple lines from top to bottom
• no-wrap : This property doe not affect the row in any manner
• wrap-reverse: This property is similar to row-reverse where it wraps the items but in reverse order that is bottom to top

flex-flow

Now that you have learned about the two properties, lets combine them with flex-flow This property is combination of flex-direction and flex-wrap and the generic syntax would be flex-flow: flex-direction flex-wrap

.container{
  flex-flow: row-reverse wrap
}

justify-content

This is one of the property which is affected by the flex-direction. This property aligns the items along the main axis which is decided by the flex-direction. For simplicity we will be using flex-direction: row.

justify-content: flex-start

justify-content: flex-end

justify-content: space-between

justify-content: space-around

justify-content: space-evenly

align-content

This property displaces the items according to cross-axis. We have taken a flex-direction: row so in the upcoming examples the displacement will occur in y-axis.

align-content: flex-start

align-content: flex-end

align-content: center

align-content: stretch

align-items

This property aligns the flex lines. It defines how the flex items should distribute vertically on the current line. It is for items in a single row. Major difference between align-items and align-content is that `align-content doesn't interfere with items in a row but with rows itself.

• stretch: Flex items are stretched to take up the leftover space.
• flex-start/start/self-start: Flex items are placed at the start of the vertical or cross axis.
• flex-end/end/self-end: Flex items are placed at the end of the vertical or cross axis.
• center: Flex items are placed in the center along with the cross or vertical axis.
• baselines: Flex items are aligned such as their baselines align.

Other Propeties

Order: This property decides the order in which elements are positioned. by default the elements have a order of 0. So, if we want to bring something to front we can assign it a lower value like order:-1 or if we want to push something to the end we can assign it a higher value.

.blacklogo{
order:-1
}

.redlogo{
order: 6
}

In the above examples we pushed the red logo at the last by give it a higher enough value. And brought the black logo in the front by applying it an lower enough value

align-self: It can be used to override the align-items by applying it to an individual element.

Setup and Initialization

This command is used to initialize an existing folder as a git repo

git init

This is used to copy a git repo

git clone [URL]

Stage and Snapshot

Show modified files in the working directory that are staged for your next commit git status

Add a file for your next commit

git add [fileName]

to add all files

git add .

unstaged a file while retaining the changes in the working directory

git reset [fileName]

check the difference between what is changed but not staged

git diff

check the difference between what is staged but not yet committed

git diff --staged

Commit staged content as a new commit snapshot

git commit -m "message"

Branch and Merge

List your branches. A * will appear next to the currently active branch

git branch

Create a new branch at the current commit

git branch [branch-name]

Switch to another branch and check it into your working directory

git checkout

merge the specified branch's history into the current one

git merge [branch]

show all the commits in the current branch's history

git log

Inspect and Compare

show the commits on BranchA that are not in BranchB

git log branchB..branchA

show the commit that changed file, even across renames

git log --follow [file]

show the diff of what is in BranchA that is not in BranchB

git diff branchB..branchA

show any object in Git in human readable format

git show [SHA]

Tracking Path Changes

Delete the files from project and stage the removal for commit

git rm [file]

change an existing file path and stage the move

git mv[existing-path][new-path]

show all commit logs with indication of any paths that moved

git log --state -M

Share and Update

add a git URL as an alias

git remote add [alias][URL]

fetch down all the branches from that git remote

git fetch [alias]

Merge a remote branch into your current branch to bring it up to date

git merge [alias]/[branch]

Transmit local branch commits to the remove repo branch

git push [alias][branch]

fetch and merge any commits from the tracking remote branch

git pull

Rewrite History

apply any commits of current branch ahead of specified one

git rebase [branch]

clear staging area, rewrite working tree from specified commit

git reset --hard[commit]

Temporary Commits

Save modified and staged changes

git stash

list the stack-order of stashed file changes

git stash list

write working from top of stash stack

git stash stop

discard the changes from the top of stash stack

git stash drop

This is pretty much all important git commands. I hope it helped. Thanks and Keep Learning!

Markdown is a plain text formatting syntax that is focused on making writing on the internet easier. It can also be considered as an alternative to WYSIWYG editors. WYSIWYG is What You See Is What You Get... MarkDown files have an extension of .md. If you have worked with Github you must be familiar with it.

It is much easier to learn and fast to use without too many tags mussing everything up.

Basic Syntax

Heading

Just like in HTML heading here ranges from 1-6 with size decreasing. # followed by space and then Heading. # Heading 1

Heading 1

## Heading 2

Heading 2

### Heading 3

Heading 3

Bold

For Bold we use ** or __ on both sides of the text **Bold** __Bold__

Bold Bold

Italic

For Italics, we use * or _

Italic Italic

Blockquote

For blockquote, we use > followed by space

BlockQuote

Ordered List

For Ordered List

1. First item
2. Second item
3. Extra

1. First item
2. Second item
3. Extra

the point here to note is that any number followed by . and space will get ordered serially. Even if we write 9. nth item the list will begin from 1

Unordered List

Unordered List we can use - followed by space

- First item
- Second item
- Third item

• First item
• Second item
• Third item

Code

Code can be written between the backticks

`code`

if we want a block of code we can have 3 such backticks /backquotes, and to highlight the code inside we can mention the language/format it's in right after the first 3 backquotes.

Horizontal Line

A horizontal line can be drawn using --- but must have an empty line above it

Link

Link can be added using

[Youtube](www.Youtube.com)

Youtube

Image

Image Addition can also be done in the same manner but we have to add ! before the entire line.

![SomeName](LinkToImage)

Extended Syntax

Table

To add a table, use three or more --- to create each column's header, and use | to separate each column.

| Syntax      | Description |
| ----------- | ----------- |
| Header      | Title       |
| Paragraph   | Text        |

StrikeThrough

You can strikethrough words by putting a horizontal line using ~~ before and after the words you want to strike.

TaskLists

Task lists allow you to create a list of items with checkboxes.

- [x] Step one
- [x] Step two
- [ ] Step Three

• [x] Step one
• [x] Step two
• [ ] Step Three

Emoji

Some Markdown supports emoji as well

Gone camping! :tent: Be back soon.

That is so funny! :joy:

Highlighting

Highlighting can be done using == on both sides of important words.

I need to highlight these ==very important words==.

Subscript and SuperScript

For Subscript we use ~ and For Superscript we use ^

H~2~O
X^3^

This is pretty much all the features of Markdown at the time of publishing this article. The features which don't have examples using the md code are not supported by the platform as of now. Thanks for Reading, Keep Learning!

The most annoying part of styling is to position that one div which refuses to obey css commands. It's frustrating and mentally draining BUT why does this happen in the first place? This Article will help you understand the nature of various positions in CSS to prevent such things from happening. There are various types of CSS Positions. We will cover them here.

Position Static

Now this is a very common position, the default position of HTML is static, This position allows a normal flow of the document and displays things as they are ordered in HTML. The top,right,left,bottom, and z-index properties do not affect position: static.

<div class="parent">
    <div class="child1"></div>
    <div class="child2"></div>
    <div class="child3"></div>
</div>

CSS

  .parent{
}
.child1{
}
.child2{
}
.child3{
}

OUTPUT

Position relative

This position stacks on top of the position static as if it contained a z-index and stacks on top of the normal flow of the document. The Offset values of top,right,left and bottom shows it. For example

HTML

<div class="parent">
    <div class="child1"></div>
    <div class="child2"></div>
    <div class="child3"></div>
</div>

CSS

  .parent{
}
.child1{
    position: relative;
    left: 50px;

}
.child2{
}
.child3{
}

OUTPUT

When we add more offset parameters

CSS

  .parent{
}
.child1{
    position: relative;
    left: 50px;
    top: 20px
}
.child2{
}
.child3{
}

OUTPUT

Effect of position: relative on table-row,table-column,table-cell elements is undefined. Also, the relative position of the element does not affect the other elements positioned in the HTML Document

Position Absolute

The absolute position removes the element from the normal flow of the document and is positioned to the closest positioned ancestor, if there is no closest ancestor it will be placedrelative to the page. After which we can assign it the offset values of top,right,bottom,left which will decide its final position

HTML

<div class="parent">
    <div class="child1">There is</div>
    <div class="child2"></div>
    <div class="child3"></div>
</div>

CSS

  .parent{
}
.child1{
    position: absolute;
    left: 100px;
    top: 30px;
}
.child2{
}
.child3{
}

OUTPUT

As you can see the child1 has been aligned according to the page and not according to its parent div. And the behavior of other elements is as if the child1 didn't exist.

Position Fixed

This is very similar to the absolute position as it will also be removed from the flow of the document/page. But fixed will always be relative to the document and is unaffected by scrolling. For example in the above HTML

.parent{
}
.child1{
    position: fixed;
    left: 100px;
    top: 30px;
}
.child2{

}

.child3{

}

OUTPUT

In the sample, you can see that even when scrolling the child1 has maintained its position according to the offset value as it is sticking to the document. It can be used to create floating elements that are always in the viewport

Position Sticky

This is a very unique position, sticky can be considered as a hybrid of the relative and fixed position. Until we reach the end of the viewport it acts as if it were relative and as soon as we cross the threshold of the viewport when scrolling, it starts behaving like a fixed. It requires at least one of the offset values to stick to.

This brings us to the end of our learning journey with CSS Position. Hope the article helped you. Thanks and Keep Learning

HTML code without styling is boring and looks horrible, CSS allows us to style the HTML skeleton and bring it to life. CSS selectors help us to select the part we want to style. It offers a variety of ways to select any given HTML component.

body {
        background-color: #d4d4d4;
}

In the above example body is the CSS Selector, background-color is the Css property and #d4d4d4 is the value for the CSS property

We will discuss the various types of CSS selectors in this Article.

Basic Selectors

The Basic Selectors are used much more than other Selectors. They are simple and easy to understand. Let us go over them.

Type Selector

Type Selector uses the HTML tags to target the field we want to style HTML

<h1>This is Heading 1</h1>

CSS

h1{ 
  color: red
}

Output

h1 here is the HTML tag and we are changing the text color by targeting the h1 tag

Class Selector

Class Selectors are widely used and can be very useful to manipulate the style of the html, it is an efficient way to style elements. We can add multiple classes to same tag separated by a space like <p class="classh2 classbold">This is a paragraph</p>. When we want to target the classes in CSS we can use "." without the quotes before the class name. Example HTML

<h1>This is Heading 1</h1>
<h2 class="classh2"> This is Heading 2</h2>

CSS

.classh2{ 
  color: blue
}

Output

We can also assign the classto other elements and the styles of the class will be applied to the other elements as well. HTML

<h1 class="classh2">This is Heading 1</h1>
<h2 class="classh2"> This is Heading 2</h2>

CSS

.classh2{ 
  color: blue
}

Output

Here we can see classh2 styles being applied to h1 after we gave it the class of classh2

Id Selectors

Id selectors are used less compared to the class selector. Id selectors should have unique ids. You can have the same id at multiple places but it's frowned upon. To Select element via Id we need to use # sign before the name of the id as opposed to . for classes. Example HTML

<h1 class="classh2">This is Heading 1</h1>
<h2 id="idforh2"> This is Heading 2</h2>

CSS

.classh2{ 
  color: blue
}
#idforh2{
 color: red
}

Output

Attribute Selectors

Now we arrived at the Attribute Selectors. In this article we will be using the Anchor tag <a></a>. CSS Attribute Selector matches elements based on the presence or value of the attribute mentioned in css file.

[attr] This just targets the tag with the given attribute HTML

  <a href="" title="some">Anchor tag with attribute title</a>

CSS

a[title] {
    background-color: purple;

  }

Output

[attr=value] This targets the attribute whose value is exactly equal to the value mentioned HTML

  <a href="notepad.com">Anchor tag with href matching notepad.com</a>

CSS

 a[href="notepad.com"] {
    background-color: green;
  }

Output

[attr*=value] This targets the attribute which has at least one occurrence of value in the mentioned attr HTML

  <a href="example">Anchor tag with href containing example</a>

CSS

 a[href*="example"] {
    background-color: rgb(51, 0, 128);
  }

Output

[attr$=value] This targets the attribute which has the value as a suffix HTML

   <a href="www.random.org">Anchor tag ending with .org</a>

CSS

 a[href$=".org"] {
    background-color: rgb(128, 0, 0);
  }

Output

[attr~=value] This targets the attribute which has the value in a set of white-space separated values HTML

   <a href="some.com" class="logo anchor blackbox">Anchor tag with class of logo</a>

CSS

 a[class~="logo"] {
    background-color: rgb(255, 0, 170);
  }

Output

Now you have an idea of how the attribute selectors work. If you want to dig deeper into Attribute selectors, please refer to MDN docs

Group Selectors

Group selectors are useful when we want to apply one style to multiple elements, we can use mention multiple attribute/tag names separated by a , to use the group selector method of selecting the HTML elements.

HTML

   <h1>This is Heading 1</h1>
    <h2 class="testing">This is Heading 2</h2>
    <h3 id="testing2">This is Heading 3</h3>
    <h4>This is Heading 4</h4>
    <h5>This is Heading 5</h5>
    <h6>This is Heading 6</h6>

CSS

h1,.testing,#testing2,h4,h5,h6{
    background-color: aqua;
}

Output

As you have seen in h2 and h3, targeting can be mixed with other attributes as well when using group selectors

Combinator Selectors

Descendant Combinator

The descendant combinator is represented by a space character like div p. Here the parent element is div and the descendant is the p tag. This combinator will match all the p tags inside of the div HTML

   <ul>
        <li>
          <div>Item 1</div>
          <ul>
            <li>Subitem A</li>
            <li>Subitem B</li>
          </ul>
        </li>
        <li>
          <div>Item 2</div>
          <ul>
            <li>Subitem A</li>
            <li>Subitem B</li>
          </ul>
        </li>
      </ul>

CSS

 li {
    list-style-type: disc;
  }

  li li {
    list-style-type: circle;
    background-color: aqua;
  }

Output

Child Combinator

This might seem like the descendant combinator but its not. There is a difference, as the child combinator targets only those elements which are a direct child of the first parent element. It is represented by > HTML

   <div>
        <span>Span #1, in the div.<br>
          <span>Span #2, in the span that's in the div.</span><br>
        </span>
      </div>
      <span>Span #3, not in the div at all.</span>

CSS

  span {
    background-color: aqua;
  }

  div > span {
    background-color: yellow;
  }

Output

An easy way to remember the difference between the two would be to consider the English meaning of the words;

• Our children are both our child and descendant
• Our grandchildren are just our descendants.

Another point to note here is that for very large websites the child selector is faster compared to descendant selectors as you have over 1000 of DOM elements.

General Sibling Combinator

This is represented by ~. It can be used to target the second element that comes after the first element. div~p will target all the p that comes after the div element. HTML

<p><strong>This paragraph will not be selected.</strong></p>

<h1>The break Point</h1>

<p><strong>This paragraph will be selected.</strong></p>

<p><strong>And this paragraph will also be selected.</strong></p>

CSS

    h1{
        background-color: aqua;
  }
    h1 ~ p {
    background-color: #FEF0B6;
    padding: 5px;
  }

Output

Adjacent Sibling Combinator

The adjacent sibling combinator + separates two selectors and targets the second element only if it immediately follows the first element and both are children of the same parent element.

HTML

<p>This example demonstrates the use of CSS</p>

<h1>The break point</h1>
<p>Vincent van Gogh Green Wheat Fields, Auvers 1890 Painting</p>

<p>Lorem ipsum dolor sit amet</p>

<h1>Break point 2</h1>
<p>Claude Monet The Japanese Footbridge 1899 Painting</p>

<p>Lorem ipsum dolor sit a</p>

CSS

h1 + p { 
    font-style: italic;
    background-color: aqua;
    font-size: 14px;
  }

Output To read more about the Combinator refer to MDN docs

Pseudo Selectors

There are two types of Pseudo selectors both provide a plethora of options for us to choose from to target the elements.

Pseudo Classes

: is used to target the special state of a particular element :hover is one such state in which the style of a particular element changes on hovering over it. Here hover is a pseudo-class. A list of such pseudo-classes can be found here

Pseudo Elements

:: This is referred to as Pseudo elements and like the pseudo-classes, this also has a variety of options. An example would be p::first-line, this will target the first line of the paragraph. To find out about the list of the Pseudo element refer here

I have tried to put light on most of the things related to selectors. For more refer to MDN docs. Thanks for reading and Keep Learning!