Developing Nerdamer

This is the practical path from cloning the repository to making and validating a change. The Nerdamer repository and its main development line are the source for current commands, file locations, and contributor guidance.

Set up the repository

git clone https://github.com/jiggzson/nerdamer.git
cd nerdamer
npm install

The source is TypeScript. Nerdamer now builds its public API modules separately from its browser bundles. The full bundle and parser-only bundle are separate targets, while build:modules produces the package subpath modules and declarations.

The normal contributor loop

Development commands

Use the repository scripts for type checking, testing, builds, documentation, and local experiments.

Full package and parser-only composition

The browser builds no longer assume that every parser entry point should pull in the complete CAS. src/index.ts assembles the complete package and calls registerNerdamerFunctions(), which registers parser-visible functions from core, math, algebra, calculus, and solving. The parser façade at src/api/parser.ts calls loadParserFunctions() instead, registering parser/core and math functionality without importing the higher-level algebra, calculus, and solver domains.

npm run build          # complete package: modules + dist/bundle.js

npm run build:parser   # parser-only browser target: dist/parser.js

This separation keeps nerdamer/parser and the parser browser target useful without recreating the old dependency from the parser back into the complete package. Domain dispatch modules register their own functions when the complete package is assembled.

Language-targeted browser builds

Browser bundles include English by default. The full and parser-only targets can include one or more translated error-message catalogs without carrying every translation. Supported language codes are spa, fra, deu, por, ita, and nld.

# Full browser bundle with Spanish

npx webpack --mode=production --env target=full --env language=spa

# Full browser bundle with Spanish and French

npx webpack --mode=production --env target=full --env language=spa,fra

# Parser-only browser bundle with Spanish and French

npx webpack --mode=production --env target=parser --env language=spa,fra

English is always included. For a targeted list, the first requested non-English language is selected initially and the other included catalogs are available for runtime switching. For example, language=spa,fra includes English, Spanish, and French, starts in Spanish, and allows the runtime LANGUAGE setting to switch to French or back to English.

When the complete package needs every translated catalog, use the named all-languages build:

npm run build:all-languages

This builds the package modules, produces the full dist/bundle.js with every language catalog, and runs the full-bundle smoke test. If only the all-languages browser bundle needs to be rebuilt, use:

npm run build:bundle:all-languages

The parser-only target can still be built with every catalog through its webpack target:

npx webpack --mode=production --env target=parser --env language=all

all cannot be combined with individual language codes. Unknown language codes fail the build. Repeated codes in a targeted list are ignored.

The normal npm run build:bundle and npm run build:parser commands omit the language option, so they produce English-only browser builds. Language targeting affects browser bundle composition; it does not replace the package module build.

Use the development scratch file

tools/dev.ts is available for experiments, debugging, and quick local checks.

import nerdamer from '../src';

console.log(nerdamer('factor(x^4-1)').text());

If tools/dev.ts imports through one of the public API package paths, such as nerdamer/core, nerdamer/calculus, or nerdamer/structures, refresh the generated module output after changing the source:

npm run build:modules

Those package paths resolve through the generated module output, so without rebuilding them the scratch file can execute stale code.

Run the development watcher with:

npm run dev

Where should the change go?

Read the code conventions

Before you finish

A change that works in one scratch example is not enough. Check the surrounding subsystem, add a targeted regression when fixing a bug, and run the full validation commands before handing the change off.

npm run typecheck
npm test
npm run build
npm run build:parser