# NotANumber: An interactive computer science and web development blog

> NotANumber is a TypeScript-oriented Next.js publication that combines technical content with interactive code examples. Its repository is more useful as a reference implementation for a content-heavy site than as a general-purpose blogging framework.

**nandanmen/NotANumber** — An interactive blog on computer science and web dev 💡

- Repository: https://github.com/nandanmen/NotANumber
- Website: https://nan.fyi
- Stars: 1,508 · Forks: 74
- Language: TypeScript
- License: not declared
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/nandanmen-notanumber

## Why NotANumber is built as an interactive publication

NotANumber is aimed at readers interested in computer science and web development, and at developers who want technical explanations to include something more executable than static prose. The repository description calls it an interactive blog, while `package.json` includes CodeSandbox packages through `@codesandbox/sandpack-react` and `@codesandbox/sandpack-themes`. The README does not explain which articles have live editors or other interactive features, so it would be an overstatement to say that every post supports executable examples. The dependency set nevertheless shows that interactive React examples are part of the implementation.

This is a personal publication implementation rather than a reusable blogging service. The repository contains `app/`, `components/`, `content/`, `experiments/`, `lib/`, `pages/`, `packages/`, `prototyper/`, `styles/`, and `public/`. Based on that directory layout, the site combines application routes, reusable interface pieces, source content, experimental work, shared libraries, and supporting packages. A reader looking for a conventional article editor, user accounts, comments, or a managed publishing workflow will not find those capabilities documented in the README.

The clearest audience is developers studying a real Next.js site or adapting its content build for their own technical publication. The project is less suitable for someone who wants a hosted, turnkey blog with no code-level ownership. It offers no documented record of published GitHub releases, either, so adopters must work from the repository rather than a release-based distribution channel.

## How the `content/` build path prepares posts

The most concrete content mechanism appears in `package.json`. The `build:content` script deletes `./_dist-content`, compiles files from `./content` with Babel, and writes the output to `./_dist-content`. Its `--extensions .ts,.tsx` option limits processing to TypeScript and TSX files, while `--copy-files` preserves other files from the source directory. Content generation is therefore an explicit build stage rather than an action attributed directly to `next build`.

During local development, the `dev` script runs two processes concurrently:

```bash
next dev
pnpm build:content --watch
```

The package manifest expresses those processes through `concurrently`. The content watcher rebuilds source material while the Next.js development server handles the web application. This split matters because a successful `next dev` process is not enough if the content compiler has stopped. An operator needs both processes to remain healthy for the expected collection of posts to appear.

A production build first regenerates the content directory and then invokes Next.js:

```bash
pnpm build
```

The site therefore has at least three content-related states to reason about: TypeScript or TSX sources under `content/`, Babel output under `_dist-content/`, and the Next.js application that renders or consumes that output. The repository includes `@next/mdx`, `@mdx-js/react`, `mdx-bundler`, `gray-matter`, and `glob`. Their presence indicates support for parts of an MDX-oriented content system, but the README does not document the exact article loader, front matter schema, or MDX entry-point convention.

## Starting NotANumber for a first local use

The README is largely the standard `create-next-app` starter text. It does not document dependency installation, the required Node.js version, or a supported pnpm version. It would therefore be unsafe to invent an exact installation command from the README. The repository does include `pnpm-lock.yaml`, and its scripts invoke `pnpm`, which identifies pnpm as the package workflow indicated by the project files.

After installing dependencies through a compatible pnpm workflow, the documented development entry point is:

```bash
npm run dev
```

The README says to open `http://localhost:3000`. Unlike the starter text suggests, the current `package.json` defines `dev` as a concurrent run of `next dev` and `pnpm build:content --watch`. A contributor editing content should also watch the compiler output for parsing failures, while changes to the Next.js application should trigger the development server.

The README directs developers to `pages/index.js` and `pages/api/hello.js`. Those instructions may describe a starter-era route layout, because the repository now has both `app/` and `pages/` and identifies TypeScript as its primary language. Confirm those files before treating them as the active home page or endpoint.

## NotANumber routing and outdated starter documentation

The repository contains both an `app/` directory and a `pages/` directory, so route ownership cannot be determined from the README alone. Next.js supports different routing systems, but the presence of `app/` by itself does not prove which routes the publication currently uses. The README specifically describes the Pages Router behavior in which files under `pages/api` map to `/api/*`.

Its documented example endpoint is:

```text
http://localhost:3000/api/hello
```

The README says that this endpoint is implemented by `pages/api/hello.js`. The repository overview does not enumerate that exact file, so its current availability is not confirmed. Likewise, the instruction to edit `pages/index.js` may no longer match the active landing page. Documentation drift is a concrete adoption concern because a first-time developer could follow the README and change a file that the current site does not use.

`package.json` also lists `@vercel/analytics`, `@vercel/postgres`, and `@upstash/redis`. Those dependencies suggest possible analytics, database, cache, or persistence integrations, but their presence does not confirm which are active or connected to visible routes. The README does not document environment variables, database schemas, Redis keys, or deployment prerequisites. These details must be verified in the route tree and configuration before treating a local fork as production-ready.

## Interactive examples and site-specific UI code

NotANumber's technical identity extends beyond a basic blog theme. Its dependencies include `@codesandbox/sandpack-react`, which supports rendering React examples through CodeSandbox tooling. The site also includes Radix UI primitives, Floating UI, Framer Motion, Motion, Jotai, XState support, and Stitches. These packages indicate a repository built around interactive controls, animation, state, and experimentation, although the README does not connect each dependency to a particular published article.

The separate `experiments/` and `prototyper/` directories suggest that experimental interface work has a defined place in the codebase. This may help a technical author who wants examples to behave like small applications instead of appearing only as static code listings. It also increases the amount of code a fork must understand. Contributors need to identify which components belong to the core publication, which are article-specific, and which experimental pieces are coupled to the site's visual conventions.

The package manifest is marked `"private": true` and has version `0.1.0`. That makes this a source repository for an application, not a documented library with a public API and a semantic-versioning promise. No GitHub releases are listed. There is no release channel for obtaining a stable theme, component package, or migration series, so repository history and `migration.md` are the relevant records when comparing revisions.

## Maintenance and licensing constraints for forks

The GitHub repository is not archived. The absence of GitHub releases also means there is no documented tagged upgrade stream, although repository commits can still record changes independently of tags.

No license is identified in the repository metadata, and the README contains no license section. An absent license does not itself supply a confirmed permission to copy, modify, or redistribute the code. That matters for a publication template because its prose, illustrations, interface design, MDX components, and interactive examples may have separate reuse considerations. This review does not offer legal advice, but the repository-level boundary is clear: do not assume that public availability grants the same rights as an explicit open source license.

Upgrade work also has an engineering cost. The repository contains `next.config.js`, `tsconfig.json`, Babel configuration, PostCSS, Tailwind, Biome, ESLint, and Vitest configuration. The package is private and carries version `0.1.0`. The README does not publish a supported dependency matrix, release policy, or complete migration procedure. Anyone comparing this site with another revision should inspect package changes and `migration.md` rather than assume that all revisions form a packaged upgrade sequence.

## NotANumber versus a plain Next.js starter

A standard `create-next-app` project begins with a small Next.js application and a conventional README like the one in NotANumber's repository. That approach is easier to grasp when the goal is to create a basic site quickly, because there is no specialized content compilation stage to coordinate. Its visible workflow centers on starting, building, and serving a Next.js application.

NotANumber adds source content under `content/`, Babel compilation into `_dist-content`, watch processes during development, custom components, experiments, and interactive React packages. This additional machinery gives an adopter a base suited to technical publishing with richer examples. The cost is a larger implementation surface. Contributors must understand the custom script chain, check output from two development processes, and verify dependencies whose article-level roles are not explained in the README.

A static site generator or hosted content management system would address different editorial needs, but the README does not compare NotANumber with either category. The distinction supported by the repository is more direct: NotANumber contains a custom content pipeline and site-specific interface building blocks, while a plain Next.js starter leaves content architecture and interaction design to the adopter.

## Conclusion

Developers building a technical blog with executable examples may find NotANumber useful after checking the content pipeline and deployment requirements. Teams wanting a conventional CMS-backed publication should first confirm that its MDX-oriented content workflow and `pnpm` build process fit their editorial process. The repository is not archived, but its last push was on 2026-05-24, and no license is documented, so maintenance continuity and reuse rights require separate review.

## FAQ

### How do I run NotANumber locally?

After installing dependencies through a compatible pnpm workflow, run `npm run dev` and open `http://localhost:3000`. The current script also starts `pnpm build:content --watch`, so the content compiler must run alongside the Next.js development server.

### How does NotANumber compile content?

The `build:content` script uses Babel to compile `.ts` and `.tsx` files from `content/` into `_dist-content/`, deleting the output directory first. The production `build` script runs this content step before `next build`.

### Can I reuse NotANumber under an open source license?

The repository metadata does not identify a license, and the README has no license section. Confirm an explicit license in the repository before copying or redistributing the code, visual assets, or publication content.

## Sources

- [Issues](https://github.com/nandanmen/NotANumber/issues)
- [nandanmen/NotANumber on GitHub](https://github.com/nandanmen/NotANumber)
- [Project website](https://nan.fyi)
- [README](https://github.com/nandanmen/NotANumber/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nandanmen-notanumber