Setup

Formal set. Ten parliamentary sittings from 2022, with audio aligned to the official minutes. Splits are whole sittings. The test set is two sittings: 456 segments, 0.91 hours, 6,036 reference words. Fifty of those segments have numbers written as digits in the minutes, which inflates word error, so I also report a no-digit subset of 406 segments (4,874 words). Development is one sitting (354 segments) and was used only to select decoding settings and vote weights. The minutes are clean verbatim: fillers and repetitions have been edited out, so some of the remaining error is editorial rather than acoustic.

Casual set. A held-out set of informal conversations: 478 scored clips, 1.12 hours, 5,995 reference words, from 148 recordings. The references are human and near-verbatim, but they use informal orthography, in which locatives such as mu and ku are often joined to the next word and apostrophes are mostly dropped. Ordinary word error therefore confounds recognition mistakes with spelling conventions.

Metrics. On the formal set I report corpus word error rate (WER), and I emphasize the no-digit subset. On the casual set, a claim has to move both an orthography-tolerant word error rate, wer_canon (apostrophes deleted and mu/ku joined to the following word on both the hypothesis and the reference), and a space-insensitive character error rate, cer_nospace. I also quote raw WER, but I do not decide claims on it. Differences are paired-bootstrap 95% confidence intervals (2,000 resamples, seed 0; formal by segment, casual by recording). All rates are in percent; a negative delta means the first system is better.

Protocol. Decoding hyperparameters were chosen on development data; the test set was scored once per system for a given experiment. The formal test set has since been reused across later experiments, so I treat it as a pilot test, not a sealed one. Headline open-model rates come from a 16 October 2026 re-score of the original hypotheses under these rules. The vote, the closed-model bake-off, and a later 23.4-hour student were scored with the same scorer after that date.

Systems. I compare Meta's Omnilingual ASR models (LLM-7B, LLM-3B, CTC-7B), public Digital Umuganda CTC models, a four-system vote, a CTC student trained on 23.4 hours of agreement-filtered labels, and closed transcription APIs. The vote combines Omnilingual LLM-7B, Omnilingual CTC-7B, and two fine-tuned CTC students; its weights were fit on the development sitting.

Results

Table 1. Word error on formal parliamentary speech and casual conversation.

Notes. Formal WER is the no-digit subset of the parliamentary test set (406 segments, 4,874 reference words), except where marked. Casual rates are on the full held-out set (478 clips, 148 recordings), except ^† the vote, which was scored only on a held-out evaluation half (229 clips, 74 recordings). ^* Gemini 4 Argon is scored on 60-second windows of consecutive clips, not clip by clip. Lower is better. I do not mark a casual winner: among the leading full-set systems the differences are small, and several of the pairwise intervals include zero.

The register gap is the main result. Omnilingual LLM-7B, the strongest single open system on formal speech, has a no-digit WER of 15.57% on the parliamentary test set and a wer_canon of 33.52% on casual conversation (raw WER 43.60%; cer_nospace 10.12%). The four-system vote lowers formal no-digit WER to 13.89%, a reduction of 1.68 points against LLM-7B (95% CI [−2.50, −0.91]). On casual speech, scored only on the evaluation half, the vote reaches 30.26 wer_canon against 33.11 for LLM-7B on the same clips; the interval is [−6.92, 0.00], and a post-hoc check found that most of the point-estimate gain comes from three recordings in which LLM-7B entered a repetition loop.

Table 2. Closed transcription APIs against the open stack on formal speech.

Notes. The screen is 40 parliamentary development clips (405 seconds of audio). A system was dropped if its screen WER was above 30 and more than 1.5 times LLM-7B on the same clips (LLM-7B screen WER 16.2). Test numbers are no-digit WER on the parliamentary test set. ^a Argon's screen number is the clip-level run; the 60-second windowing was selected later, on the full development sitting, and then scored once on the test set.

Closed APIs did not overtake the open stack. On the 40-clip formal screen, three OpenAI transcribers landed between 79.89 and 89.39% WER and were not run on the test set. Grok STT and MAI Transcribe 2 were above 100%. Only Gemini 4 Argon survived (19.69%). Scored clip by clip on the parliamentary test set, Argon has a no-digit WER of 22.51%, 8.62 points behind the vote ([7.04, 10.20]). Much of that gap is a clip-end failure. Mid-clip, on the same test comparison, Argon ties LLM-7B (−0.18 [−1.67, +1.31]). On the development sitting, Argon got the last word wrong in 41% of no-digit clips, against 6% for LLM-7B. After selecting 60-second windows of consecutive clips on development data, Argon reaches 17.76% no-digit WER on the test set. That is 3.50 points behind the vote ([1.28, 5.97]) and statistically tied with LLM-7B (+1.28 [−1.46, +4.36]). On casual conversation the windowed system does not beat the pre-registered best open student on both casual metrics (wer_canon 32.03 vs 33.27, interval [−2.99, +1.35]; cer_nospace 11.79 vs 10.31, interval [−0.13, +3.86] in the other direction).

Table 3. Fine-tuning the Digital Umuganda 660-hour model on human minutes versus agreement-filtered machine labels, LM decode.

Notes. Formal WER is no-digit, parliamentary test, LM decode. Casual wer_canon is the full casual set. Deltas are paired-bootstrap 95% intervals (2,000 resamples, seed 0). The filtered 2.4-hour arm is not different from the 6.0-hour human arm on formal no-digit WER under greedy decode (−0.18 [−0.96, +0.60]); the LM-decode point estimates above are likewise within about a quarter of a point of one another.

Agreement-filtered machine labels match human labels on formal speech and do not close the casual gap. Fine-tuning on 6.0 hours of official minutes cuts formal no-digit WER by 3.00 points with a language model, but it raises casual wer_canon (+2.89 [+2.04, +3.75]). The same student trained on 2.4 hours of LLM-7B labels, kept only where a second system agrees, matches the human-label arm on the formal test set and does not reliably improve casual wer_canon against the untrained model. Looser keep thresholds, and machine labels drawn from casual audio, similarly fail to move both casual metrics together.

A later student trained on 23.4 hours of filtered labels continues the formal trend (no-digit WER 18.51 with a language model, 3.86 points better than the untrained baseline, interval [−4.79, −3.00]) and still leaves casual wer_canon at 32.85, within noise of the untrained model (−0.59 [−1.44, +0.30]).

Analysis

Formal Kinyarwanda, at least in this parliamentary domain, is already in a usable range for an open 7B speech LLM, and a vote takes another one to two points off. Casual conversation is a different problem: even an orthography-tolerant metric stays in the low thirties, and neither closed APIs, nor fine-tuning on formal minutes, nor scaling agreement-filtered labels to a few tens of hours closes it. The vote's apparent casual gain is too concentrated to treat as a general improvement.

A screen on short segments misrepresented Gemini 4 Argon as a long-form system. Fixing the clip-end artifact was not enough to beat the open vote on formal speech.

Limitations

The official minutes are edited, so formal WER includes an unknown editorial floor. The casual references are informally spelled; wer_canon and cer_nospace are designed for that, but they remain automatic metrics against one annotation style. The parliamentary test set has been scored in many decisions and is no longer clean. The 60-second Argon condition is not a clip-level comparison. The vote's casual result uses only half the casual set. I do not yet have a sealed, human-transcribed casual or broadcast test set of comparable size.

Next measurements

The next formal claims should be scored once on a sealed set that has not been used for selection. The casual gap needs human-corrected conversational transcripts, not more machine labels of the current quality. I will also keep the vote as a teacher for a larger CTC student, and only then re-measure both registers.

Setup

Tasks. The core suite is the AfroBench-Lite Kinyarwanda slice used in the AfriqueLLM paper: AfriMGSM (250 items, exact match, chain-of-thought), AfriMMLU (500, 4-way accuracy), AfriXNLI (600, 3-way accuracy), Belebele (900, 4-way accuracy), SIB-200 (204, 7-way accuracy), Injongo intent (640, 40-way accuracy), and FLORES-200 English↔Kinyarwanda (1,012 sentences per direction, chrF++). FLORES is loaded from Meta's official FLORES-200 release, not the gated Hugging Face copy.

Protocol. Instruct checkpoints are run in the model's own chat template, 0-shot, greedy. Thinking is forced off (enable_thinking=False as a top-level model argument; nesting it inside chat-template arguments is silently overwritten by lm-eval's vLLM wrapper). Every generated answer is scanned for thinking markers; a leak would invalidate the run. This first pass uses prompt variant 1 only, so these scores are for a single prompt, not a best-of-prompts number. Multiple-choice tasks are scored by log-likelihood after the assistant prefix. I used EleutherAI lm-eval 0.4.13 and vLLM 0.31.0, on one A40, in bfloat16, with a 16,384-token context.

Models. McGill-NLP/AfriqueQwen3.5-4B-50Langs-Instruct-v1 (revision 0ff0ff64) and McGill-NLP/AfriqueQwen3.5-9B-50Langs-Instruct-v1 (revision 693f12e4). Both are CC-BY-4.0. For context I also copy the paper's 5-shot scores for the 4B base 50-language checkpoint. That row is a different model and a different protocol; it is not a direct baseline.

Results

Table 1. KinyaBench public-track scores, 10 October 2026. Chat protocol, 0-shot, prompt 1, thinking off.

Notes. Intervals are the lm-eval standard error, not a 95% confidence interval. Bold marks the better of the two instruct runs, which are the only scores from this protocol. The paper column is AfriqueQwen3.5-4B-50Langs, base, 5-shot (AfriMGSM 8-shot), from appendix tables of arXiv 2601.06395 v3. It is shown for orientation, not as a matched baseline. AfriMGSM is flexible-extract exact match; strict-match is 0.0 for both instruct models.

The 9B model is ahead on seven of the eight tasks. The gap is largest on Belebele: 62.0% against 35.6% (standard errors 1.6 points). Because the same harness, on the same 4B checkpoint, lands close to the published FLORES numbers (46.12 chrF++ for English→Kinyarwanda against 46.39 in the paper, 51.81 against 53.04 in the other direction), the 4B's weak multiple-choice scores are a property of the instruct model under this protocol, not a scoring bug.

AfriMGSM is the exception: 46.0% exact match for the 4B, 39.2% for the 9B. These are thinking-off, greedy, 0-shot figures and are not comparable to the McGill model-card numbers, which use thinking and a long generation budget. AfriXNLI, which sits near chance (33.3%) for every model in the paper, is 43.7% for the 4B and 56.2% for the 9B under chat 0-shot.

Thinking markers leaked in none of the audited generations (FLORES both ways, and AfriMGSM). The 9B AfriMGSM run had one empty completion out of 250.

Analysis

A 9B African-continued Qwen3.5 is, under this protocol, a clearly stronger Kinyarwanda reader than its 4B counterpart, especially on Belebele and SIB-200. Translation is already close to the published base-model figures at 4B, and a little higher at 9B. I have not yet run the paper's own protocol (raw 5-shot, on the base checkpoint), so I cannot claim a reproduction of the comprehension rows. I have also not yet run a Qwen3.5-9B instruct model without the African continued pretraining, so this note does not isolate that training stage.

Limitations

One prompt variant, two models, no base-protocol validation run. AfriXNLI remains a weak signal in the literature even when the 9B is well above chance here. The native, locally written track has no automatic scorer yet, so I am not reporting assistant-quality numbers. SSA-COMET, the paper's headline FLORES metric, is not implemented; I compare chrF++ with the paper's appendix.

Next measurements

The same protocol with all prompt variants; a base-protocol run of AfriqueQwen3.5-4B-50Langs; Qwen3.5-9B instruct without African continued pretraining; and Gemma 4 26B-A4B and 31B, which have no published Kinyarwanda scores I can find. After that, continued-pretraining models from my own pack can be placed on the same scale.

The aim was a native Kinyarwanda language model: continued pretraining of an open 8–9 billion-parameter base on a few hundred million clean tokens, then supervised fine-tuning. I finished a full-parameter run of Qwen3-8B, a LoRA adaptation of Qwen3.5-9B, and an instruction-tuning run that I served to testers. Held-out pack perplexity on the 8B run fell from 10.44 to 5.50; the LoRA run moved only 8.07 to 7.84. The served system failed a manual quality review. When I returned to the work in October I treated those results as a reason to measure existing models before training new base weights.

The pipeline

The factory mined, language-identified, filtered, and deduplicated documents, then packed them as input_ids sequences with no residual text column. A new base therefore needs retokenization from the document shards. Training and evaluation lived in separate codebases: a continued-pretraining loop with configs, checkpoints, and a promotion gate that I only ever ran dry; a supervision pipeline that generated, cleaned, and split instruction data; and a small evaluation and serving stack for a tester chat surface.

The pack

On 27 February 2026 I exported a packed training split of 183,083,577 tokens under the Qwen3 tokenizer (411,133 documents, 44,699 sequences, maximum length 4,096), with 2,026,316 validation tokens and 2,047,384 test tokens. The source-token estimate before packing is 178,795,577 tokens across 420,301 documents.

Table 1. Estimated source-token composition of the pack, by type.

Notes. Token counts are the factory's pre-pack estimates, summing to 178,795,577. The official packed training split is 183,083,577 tokens. Official documents combine institutional publications; web crawl combines index-targeted and language-filtered Common Crawl slices.

A random sample of Common Crawl WET files produced no Kinyarwanda: 0 documents in 114,254, even at a language-identification threshold of 0.50. The web-crawl tokens that did enter the pack came from index-targeted and language-filtered extraction, and they remain 0.7% of the estimate.

Filters included language identification, length, boilerplate and template phrases, and near-duplicate removal. A mid-pipeline deduplication pass on 29 of 32 shards flagged 11,052 exact and 1,212 fuzzy duplicates of 409,332 documents (3.0%). I do not treat that as a statistic for the final pack, because three shards were not in that report.

On 28 February I ran a recall-first clean of the mbazaNLP slice: 210,832 of 390,562 documents were kept (54.0%), holding 103,609,913 of 125,091,104 estimated tokens (82.8%). Most discards were short fragments; only 35 documents were hard-rejected, all on a combined template-phrase and low language-ID signal. That clean was packed as a 161,244,925-token training split. It is not the 183-million-token export above, which still includes the uncleaned mbazaNLP slice.

A later, more aggressive retokenization under Qwen3.5, in four cleaning versions, ends at 144,146,803 tokens (304,411 of 420,301 documents kept). That pack is not the continued-pretraining run below.

Tokenizer cost

On FLORES-200 devtest (1,012 parallel sentences; 20,077 Kinyarwanda words and 21,901 English words, whitespace-split) the candidate base tokenizers all cost about twice as many tokens for Kinyarwanda as for the same English content. Gemma 4 26B-A4B is the most compact of the three, and the spread among them is small: 2.66 to 2.90 Kinyarwanda tokens per word, an 8% difference in sequence length between Gemma 4 and Qwen3. Qwen2.5-7B and Qwen3-8B produce identical token counts on this set; so do Qwen3.5-9B and AfriqueQwen3.5-9B-Instruct.

Table 2. Tokenizer fertility on FLORES-200 devtest.

Notes. Encoded with the tokenizers 0.23.3 library from the local Hugging Face tokenizer files, without adding special tokens (adding them does not change the counts). Words are whitespace-split. Qwen2.5-7B and Qwen3-8B differ in vocabulary size but not in token counts on this set; the same is true of Qwen3.5-9B and AfriqueQwen3.5-9B-Instruct. English tokens per word are 1.26, 1.26, and 1.24 respectively.

I also trained 16,000-piece Unigram models on a stratified shard of the corpus. On the held-out slice in Figure 2, a custom trainer reached 5.08 characters per token against 4.39 for SentencePiece trained on the same shard. The custom trainer was about two orders of magnitude slower (166.6 s versus 1.79 s on a 1,024-document shard, and 359.8 s versus 3.31 s on a 3,072-document shard) and hit RecursionError on larger representative shards. A custom vocabulary also cannot be dropped into a pretrained model without relearning embeddings. I parked the tokenizer.

Training

I configured two continued-pretraining recipes: full-parameter Qwen3-8B on a 183-million-token target (learning rate 1×10⁻⁵, sequence length 2,048, Adafactor), and LoRA on Qwen3.5-9B (rank 32, α 16, dropout 0.05, on q_proj and v_proj only; learning rate 2×10⁻⁵) with a 150-million-token target. A later, higher-capacity LoRA configuration (rank 256, α 512) was started and crashed early.

The Qwen3-8B run finished on 2 March 2026: 11,170 steps, 183,007,801 tokens seen (one pass over the February pack, short by 75,776 tokens) in 22.46 hours (2,267 tokens per second). Validation was logged every 500 steps. I have no measurement of the unadapted base on the same split, so the first point is step 500, not step 0. Held-out perplexity fell from 10.44 at step 500 to 5.50 at step 11,000. The best logged value is 5.45 at step 6,500, after 106.5 million tokens; after that the curve is nearly flat, ending at 5.50. Mean training loss was 3.72 over the first 50 steps and 1.89 over the last 50. A 20-million-token sanity on the same recipe, earlier that day, had already moved validation perplexity from 14.42 at step 200 to 9.25 at step 1,200. An earlier full-run start stopped at 161 steps with no validation logged. No test-split metric was logged for any of these runs.

The Qwen3.5-9B LoRA adaptation ran overnight on 13 March 2026: 2,289 steps, 150,010,227 tokens seen, 11.02 hours, 3,780 tokens per second. The training file was a retokenized pack under the Qwen3.5-9B tokenizer, not the February Qwen3 export directly. Validation was logged every 500 steps. Held-out perplexity fell from 8.07 at step 500 to 7.84 at step 2,000, a drop of 0.23 over 1,500 steps. Mean training loss was 2.252 over the first 50 steps and 2.099 over the last 50, and the curve had already flattened in the second half of the run. No downstream task evaluation of this adapter was logged.

The higher-capacity LoRA attempt crashed after a last logged optimizer step of 240, with training loss 2.27 → 2.09 over the twelve logged points. No validation was recorded: evaluation was scheduled every 500 steps.

Table 3. Training runs from the February–April programme.

Notes. Validation figures are the first and last logged held-out values, except the SFT row, which ends at the best validation loss (step 4,000; perplexity 3.26). The 8B continued-pretraining best is 5.45 at step 6,500; the last logged value, at step 11,000, is 5.50. LoRA perplexities are at steps 500 and 2,000; the run continued to step 2,289 with no further validation. The higher-capacity LoRA log has no tokens-seen field. The SFT run failed during the second of three planned epochs; at step 6,000, validation loss was 1.199. No step-0 base-model validation was recorded. GPU type was not recorded. An instruction-tuned checkpoint from the SFT recipe was served and reviewed, as described below.

The two completed continued-pretraining runs are not on a comparable vertical scale. The 8B full-parameter run moves held-out perplexity by 4.94 points; the LoRA run moves it by 0.23. Neither includes a step-0 base-model point, and neither was followed by a task evaluation of the continued-pretraining checkpoint itself.

Supervision

Between 7 and 9 March I built a 32,433-row instruction set, split 29,146 / 1,601 / 1,686 for train, validation, and test. Every response was written by GPT-5.4. Automatic cleaning kept 26,515 of 26,525 single-turn answers (nine rejected as too short, one as a duplicate prompt–response pair) and all 5,918 multi-turn chat pairs.

A pre-registered mix check against the lab's own plan failed eleven slices. Language composition is the clearest of those failures.

Table 4. Language modes in the 32,433-row supervision set, against the planned floors.

Notes. Floors are from the lab mix plan. The other failed slices are content types below their floors: multi-turn chat 18.2% against 20%; safety refusals 0.84% against 6%; noisy-input robustness 0.61% against 6%; code-switching 3.8% against 7%; multilingual retention 0.88% against 3%; language control 0.84% against 2%. Kinyarwanda instruction rows, at 31.8%, cleared their 20% floor.

The set is almost entirely Kinyarwanda teacher text, with 16 English rows, three French, and no Swahili. I configured a three-epoch full-parameter SFT run of the Qwen3-8B continued-pretraining checkpoint on this set (learning rate 8×10⁻⁶, sequence length 2,048). A 200-step sanity finished the same day with validation loss 1.318. The main run failed at step 6,000, during the second of the three planned epochs, after 12,144,794 supervised tokens and 3.49 hours. Validation loss fell from 1.402 at step 500 to a best of 1.182 at step 4,000 (perplexity 3.26), then rose slightly to 1.199 at the last logged step. Training and validation loss both jumped near the epoch boundary at step 3,645; the best validation point is early in the second epoch. Training loss kept falling, to 0.696 at step 6,000. An instruction-tuned checkpoint from that recipe was served.

Evaluation

On 11 March I reviewed the seven conversations captured from the tester chat surface (34 generations; a broader export of ten conversations contains 37 generations). One of the seven was clearly acceptable. The others failed on identity, on basic facts about Rwanda, on instruction following, or on repetition and unnatural Kinyarwanda. The review called this a failed quality pass, and not a problem that a prompt change would fix.

A concurrent 200-item internal evaluation set was run on the base model, on the instruction-tuned system, and later on untuned Qwen3.5-9B. Those runs were never quality-scored: the pipeline recorded HTTP success, not graded answers. I do not report those automatic pass rates here.

What this implied

A perplexity drop on a held-out pack is not a quality gate. Full-parameter continued pretraining moved held-out perplexity from 10.44 to 5.50, and after supervised fine-tuning on the GPT-5.4 responses, the served system failed a human review. 150–183 million Kinyarwanda tokens, used as full-parameter or low-rank continued pretraining, did not produce a usable model at this scale of measurement. A 32,433-row teacher-written supervision set, almost without English or French replay and already off its own mix plan, did not produce acceptable assistant behaviour in that review.

When I returned to the work in October I treated those findings as settled. I stopped training new base weights on a few hundred million tokens, parked the custom tokenizer, and turned to measuring public-track scores for open models, and to a speech-recognition lab, before any further continued pretraining. The public-track results are in a separate note.

React 18 changed how a library must subscribe to store updates. The supported path is useSyncExternalStore, which Recoil adopted in 0.6 on 28 January 2022 (#1488). The hook exists so an external store cannot tear under concurrent rendering: React reads a consistent snapshot for that render. It also requires a getServerSnapshot for server render. Without that function, Next.js apps failed during SSR (#1526). Some host environments, including nested renderers, exposed a React 18 dispatcher but not the hook itself, which produced useSyncExternalStore is not a function. Recoil added a fallback in 0.7.6 (#2001, #2010), and further Next.js 13 SSR fixes in 0.7.7 (#2082, #2086). Application and test code had their own breaks: ReactDOM.render gave way to createRoot, and act moved from ReactTestUtils into the react package. Chatmaid's upgrade hit this class of failure.

The last Recoil release, 0.7.7, shipped on 1 March 2023. The last upstream commit was on 7 September 2023. A planned handover to external maintainers stalled after the remaining public maintainers were laid off (discussion #2171). Meta archived facebookexperimental/Recoil on 1 January 2025.

The fork

I created Mutesa-Cedric/Recoil-next on 27 November 2024, a month before the archive. The next day, in fb238a5, I raised the peer dependency from react >= 16.13.1 to react >= 18.3.1, switched the example app to createRoot, and replaced ReactTestUtils.act with act from react. That commit updates the package metadata together with the test and example trees, 44 files in all. The current peer range is react >= 18. The development tree uses React 19.1.1, and the test matrix covers React 18 and React 19 on Node 20 and 22.

TypeScript

Recoil was written in Flow. On 6 July 2025 I started a port to TypeScript (c09d731). This was a rewrite of the sources, not a types layer over Flow. Shared utilities, the ADT and cache layers, atoms, selectors, hooks, and RecoilRoot all moved before the first publish. The core package was complete on 16 July (ecb69f0). I then ported recoil-relay, recoil-sync, and refine. Pull request #1 landed on 8 August and made the TypeScript tree the repository root.

The build moved to Rollup, emitting ESM and CommonJS with generated typings. Tests moved from Jest to Vitest. The workspace uses pnpm. ESLint is on v9. The ported core test tree has 43 files and 284 test/it cases. I published the rewritten package as recoil-next 0.1.0 on 28 July 2025. It has been downloaded more than 350,000 times since then.

Migration is an import change, and that is the only required code change. The Recoil API is unchanged, so the original Recoil documentation still applies:

// Before
import {atom, selector, useRecoilState} from 'recoil';

// After
import {atom, selector, useRecoilState} from 'recoil-next';

Version 0.2.0, on 10 August, stopped react/jsx-runtime from being bundled into the output (f327be4) and updated the todo example to use recoil-next. On 15 August the ported recoil-core, recoil-sync, and recoil-relay tests were passing. I added __DEV__ support and published 0.3.0.

recoil-next@0.4.4 ships an unminified ESM build of 204 KB, 41.7 KB gzipped. Recoil 0.7.7's unminified es/index.js is 275 KB, 63.0 KB gzipped.

The NaN loop

An atom whose default was NaN could throw Maximum update depth exceeded as soon as a component read it:

const Atom = atom({
  key: 'myKey',
  default: NaN,
});

export default function Test() {
  const val = useRecoilValue(Atom);
  return <div>{val}</div>;
}

Loadable.is() compared contents with ===. In JavaScript, NaN === NaN is false, so two loadables holding NaN looked different on every check. Recoil uses that equality to decide whether a value has changed and subscribers must re-render, so the store kept updating. The fix is Object.is, which treats NaN as equal to itself:

is(other: Loadable<any>): boolean {
  return (
    (other as any).state === (this as any).state &&
    Object.is((other as any).contents, (this as any).contents)
  );
}

That change is 2342fff, documented in #3. It shipped in 0.4.0 on 7 November 2025.

One package

After the TypeScript port, recoil-relay, recoil-sync, and refine still lived in the same workspace as core. Those packages are optional integrations, not the Recoil API. I published the companions as recoil-relay-next and refine-next on 18 August 2025. On 28 December, pull request #4 removed them from this repository. A core install is the Recoil API and nothing else. recoil-next@0.4.4 was published on 26 January 2026.

The public API is still the Recoil one, including atoms, selectors, hooks, and RecoilRoot. The sources are TypeScript, and the build emits ESM and CommonJS for React 18 and 19.

How Node chooses

The packages documentation is the source of truth. For a file Node is asked to run or import:

• .mjs is always an ES module, regardless of the nearest package.json.
• .cjs is always CommonJS, for the same reason.
• .js follows the nearest parent package.json. "type": "module" makes it ESM; "type": "commonjs", or no "type" field at all, makes it CommonJS.

.mjs therefore needs no package configuration. This is the example I used in 2023, and it still runs with node main.mjs:

// mathUtils.mjs
export function add(a, b) {
  return a + b
}

export function multiply(a, b) {
  return a * b
}

// main.mjs
import { add, multiply } from './mathUtils.mjs'

console.log(`Sum: ${add(5, 3)}`)
console.log(`Product: ${multiply(4, 2)}`)

The extension is the signal. The same import in a .js file is a syntax error unless that file is already in an ESM scope. File extensions override "type", which is how you mix formats in one package: a "type": "module" package can still keep a CommonJS file by naming it .cjs, and a CommonJS package can keep an ESM file by naming it .mjs.

Package authors should set "type" explicitly, even when every file is CommonJS. Node may change the default later, and tools should not have to guess. Since Node 22.7 and 20.19, an ambiguous .js file (no "type" in scope) is also subject to syntax detection: if the source can only parse as ESM, Node retries it as ESM. That has a cost, and it is a fallback, not a reason to omit "type".

import and require also resolve specifiers differently. A relative or absolute import must include the file extension, and directory indexes have to be written out (./startup/index.js, not ./startup). require('./startup') will still search .js, .json, and .node, and will still treat a folder as a module.

What .mjs is not

ESM can be statically analysed. Bundlers use that to drop unused exports, which is tree shaking. If main.mjs only imports add, a bundler can omit multiply from the output. That is a property of import / export, not of the .mjs extension, and it is not something Node does when you run node main.mjs. I overstated this in 2023.

Dynamic import() is not an .mjs feature either. It is available in both CommonJS and ESM, and it is the way a CommonJS file loads an ES module when it needs to do so asynchronously:

const { add } = await import('./mathUtils.mjs')

In a browser, the decision is the script's type="module" (and the JavaScript MIME type the server sends), not the file extension. .mjs is not special there. Bare specifiers such as import 'lodash' also do not resolve in a browser without an import map, and Node built-ins do not exist there. ESM is a shared syntax, not a promise that the same file runs unchanged on both sides without a bundler.

An ES module has to name its dependencies in import statements, and top-level bindings stay in the module. They are not written onto a shared exports object, and they do not leak into other files. That is the practical difference from CommonJS, and it is why I preferred ESM in 2023.

Packages: "exports" and the dual-package hazard

For a package, "main" is only the default entry. "exports" replaces it when present: it can list subpaths, and it hides anything not listed. Consumers of pkg/hidden.js get ERR_PACKAGE_PATH_NOT_EXPORTED.

Conditional exports then pick a file based on how the package is loaded. "import" and "require" are mutually exclusive. Key order matters; more specific conditions go first, and "default" last:

{
  "type": "module",
  "exports": {
    "import": "./index.mjs",
    "require": "./index.cjs"
  }
}

That pattern is common, and it has a cost. If one part of an application imports the package and a dependency requires it, Node can evaluate two different files and keep two copies in memory. Constructors then fail instanceof across the boundary, and mutations of a singleton on one copy are invisible to the other. Node's name for this is the dual package hazard; the current docs point at the package examples repository for the worked cases. The usual mitigations are to wrap a single CommonJS implementation for import, or to isolate any state in one shared file that both entry points load.

require(esm)

Until recently, require() of a native ES module threw ERR_REQUIRE_ESM. That is why so many packages shipped a separate .cjs build. Loading ESM with require() was unflagged in Node 22.12 and 20.19, and in current Node it is stable (as of 25.4). The module must be synchronous. If the graph contains top-level await, require() throws ERR_REQUIRE_ASYNC_MODULE and you should use import() instead.

const { add } = require('./mathUtils.mjs')
const Point = require('./point.mjs').default

The return value is the module namespace, so a default export is on .default. A package that only needs to support these Node versions can ship ESM and let both import and require load the same file, which removes the split that causes the hazard:

{
  "type": "module",
  "exports": "./index.js",
  "engines": {
    "node": "^20.19.0 || >=22.12.0"
  }
}

The "module-sync" exports condition matches that same synchronous-ESM case for both loaders.

.mjs remains the local way to force a format. "type" does the same at package scope. A split "import" / "require" pair is a compatibility choice with a real failure mode, and it should not be the default shape of a new package.