npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@codincod/codemirror-lang-swift

v0.1.1

Published

Swift language support for the CodeMirror code editor

Readme

@codincod/codemirror-lang-swift NPM version

[ CHANGELOG ]

This package implements Swift language support for the CodeMirror code editor, using a Lezer grammar written for this package.

CodeMirror 6 has never shipped Swift. What it offers is the stream mode ported from CodeMirror 5, which colours a list of keywords and leaves no tree behind, so nothing above it can fold a function, indent a switch or ask what the word under the cursor is. No Lezer grammar for Swift existed anywhere before this one.

Written in part for CodinCod, a competitive coding platform, where it colours the editor people solve puzzles in.

This code is released under an MIT license.

Usage

import {EditorView, basicSetup} from "codemirror"
import {swift} from "@codincod/codemirror-lang-swift"

const view = new EditorView({
  parent: document.body,
  doc: `struct Greeter {
    let name: String

    func greet() {
        print("Hello, \\(name)!")
    }
}
`,
  extensions: [basicSetup, swift()]
})

Coverage

Swift 5.9. Async and await, actors, structured concurrency, opaque and existential types (some and any), property wrappers, result builders, macros, parameter packs, pattern matching, generics with where clauses, key paths, multi-line and raw strings, operator and precedence group declarations. The Swift 1 and 2 spellings a decade of published code still carries are in too: inout in front of a parameter name, var parameters, curried functions, and constraints written inside the angle brackets.

Measured against 724 Swift files from Rosetta Code, 94.34% parse with no error node. Most of the rest is the C-style for loop that Swift 3 removed, and a handful of files that are C rather than Swift.

What a tokenizer has to settle

Almost all of Swift can be written down as a grammar. Five things cannot, and they are the whole of tokens.ts.

Whitespace decides what an operator is. Swift's operator set is open, so a - b, a -b and a-b cannot be told apart by spelling. The language settles it by spacing: an operator with space on both sides or neither is infix, one with space only in front is prefix, and one with space only behind is postfix. The same rule separates x! from !x, and a ?? b from x?.y.

An angle bracket is two different things. Array<Int> opens a generic argument list and a < b compares. Where a type is expected the parser has already ruled the comparison out. Where an expression is expected, the tokenizer reads ahead for the closing bracket and takes the call or member access that follows it as the proof.

A brace is two different things. if x { } is a condition and a body; xs.map { } is a call and a closure. Swift tells them apart by where the brace stands, so the tokenizer asks the parser whether a body could stand here and lets the answer decide. A closure that opens with a signature ({ x in ... }) is a third case, found by reading ahead for the in over nothing but what a signature may hold.

Block comments nest. A comment opened inside a comment has to be closed twice, which no regular token can count.

A string holds code. "total: \(a + b)" is a string with an expression inside it, and that expression may hold another string. The tokenizer cuts the string into pieces and the grammar parses what lies between them.

What the tree does not say

Two things are deliberately shallower than the language reference.

Operator precedence is flat. Swift lets anybody declare an operator and give it a precedence group, so no fixed table here could be right about a program it has not seen. Infix operators are one left-associative level, which is wrong about the shape of a + b * c and right about every operator this grammar has never heard of. A highlighter reads tokens rather than shapes.

Patterns are expressions. case .some(let x) holds a binding that only appears in a pattern. Rather than carry a second grammar for patterns, let x is accepted as an expression and the tree says BindingPattern where a pattern was written.

Raw strings (#"..."#) are one token rather than a parsed string, because the delimiter's pound count would have to be carried from the opening token to the closing one. Nothing interpolates inside them anyway.