Angular Snippets for VS Code: a catalogue of 60 prefixes and their trade-offs

The manifest contributes one snippet file per language

The mechanism is the standard VS Code snippet contribution point, and the extension uses one file per language. The package contributes snippets for five languages, each pointing at a JSON file in the snippets directory:

  "contributes": {
    "snippets": [
      {
        "language": "typescript",
        "path": "./snippets/typescript.json"
      },
      {
        "language": "javascript",
        "path": "./snippets/javascript.json"
      },
      {
        "language": "jsonc",
        "path": "./snippets/jsonc.json"
      },
      {
        "language": "html",
        "path": "./snippets/html.json"
      },
      {
        "language": "dockerfile",
        "path": "./snippets/dockerfile.json"
      }
    ]
  },

That structure is worth understanding once. Adding a snippet means editing a JSON file in the snippets directory, not touching extension code, and the language scoping is handled by the manifest. The presence of a jsonc entry is a small sign of attention to detail, since jsonc is what VS Code uses for its own settings files and for tsconfig.

The rest of the manifest shows the shape of a modern extension. The package name is Angular2, the publisher is johnpapa, the display name carries the Angular version, the icon and gallery banner are declared, and the categories are Snippets and Other. The extension is declared as both ui and workspace kind, and it declares the virtualWorkspaces capability, which is what lets it run in a virtual workspace such as a remote or virtualised file system.

The engine requirement is vscode ^1.40.0, which is a very old floor and tells you the extension does not depend on recent editor APIs, even though the catalogue tracks current Angular.

The TypeScript catalogue is the product

The Angular TypeScript snippets table is the core of the extension, and it is organised by what you are trying to create rather than by API name.

Components come first, and in four flavours: a-component for a component, a-component-standalone for a standalone component, a-component-inline for a component with an inline template, and a-component-root for the root app component. The distinction between standalone and module based is the one that has changed the most over the last few releases of Angular, and having both a-component and a-component-standalone means the snippet set can follow whichever model you are on.

Then the platform pieces. a-directive, a-pipe, a-resolver, a-service for a service injectable in root, a-service-httpclient for a service with HttpClient, and a-output-event for an output event and emitter. Routing is the most granular group: a-routes for a route definition file, a-module for a module and a-module-root for the root app module, and then a family of route path snippets for 404 paths, default paths, paths with children, eager paths, lazy paths for module loading and lazy paths for standalone component loading.

Guards have their own set matching the modern functional guard functions: a-guard-can-activate, a-guard-can-activate-child, a-guard-can-deactivate and a-guard-can-match, matching CanActivateFn, CanActivateChildFn, CanDeactivate and CanMatch.

The HTTP group is the one with real value in a codebase that talks to an API. a-httpclient-get produces an httpClient.get call with an Rx Observable, a-http-interceptor is an empty Angular HttpInterceptor for HttpClient, and the two variants set headers and log traffic.

There is also a small set of odds that ends of the catalogue: a-rxjs-import and a-rxjs-operator-import for RxJS features and operators, a-subscribe for an Observable subscription, a-trackby for a trackby function in a ngFor, a-router-events to listen to router events, a-route-params-subscribe to subscribe to route parameters, a-ctor-skip-self for the NgModule skipself constructor, and two preload strategy snippets, one that lets you choose which routes to preload and one that preloads based on network connectivity.

NgRx, Docker and Express snippets sit in the same extension

The extension is not only about Angular templates, and the other tables are where the catalogue shows its age and its reach.

The NgRx table is a set of ten snippets covering the state management library: a-ngrx-store-module to create a store module, a-ngrx-create-action and a-ngrx-create-action-props for actions, a-ngrx-create-reducer, a-ngrx-create-effect and a-ngrx-create-effect-api for an effect that calls an API, a-ngrx-create-selector and a-ngrx-create-selector-props, and the entity helpers, a-ngrx-data-entity-data-module-import to add EntityDataModule, a-ngrx-data-entity-metadata for the entity metadata and a-ngrx-data-entity-collection-data-service for a data service.

The Dockerfile table has one entry, docker-angular-node-multi-stage, for a multi-stage Dockerfile with Node and Angular. That is a genuinely useful snippet, because writing a multi-stage build by hand is tedious and easy to get wrong in the same way every time.

The JavaScript table has one entry too, ex-simple-server, for a Node.js Express server. It is the odd one out in a TypeScript-first extension, and it reads more like a convenience for a quick backend than a systematic snippet set.

The HTML table is where the extension was originally most useful, with a-class for a class binding, a-select for a select control and a-style, where the README table is cut off mid-row.

There is also a cross-reference to another extension. The Angular Essentials extension is recommended for more extensions for developing with JavaScript and Angular, and the repository links to an AI Ready project, which is the kind of marker that tells you the maintainer cares about the tooling around the extension rather than only the snippets.

Two ways to trigger a snippet, and what happens after

Using the extension is as simple as it sounds, and the README describes it in one line. Type part of a snippet, press enter, and the snippet unfolds.

The alternative is the manual invoke shortcut, which is Ctrl+Space on Windows and Linux and Cmd+Space on macOS, to activate snippets from within the editor. The prefix matching is the standard VS Code behaviour, so typing a-component and accepting the completion is the same interaction as any other snippet in the editor, which means the muscle memory transfers from other snippet sets you already use.

What deserves attention is the part the README does not spell out, because it is the same for every snippet extension. A snippet produces text, and the text it produces is one author's idea of the right shape for that construct. Whether a component comes with a styleUrls array, an inline template, a change detector strategy set to OnPush or a subscribe call left in the constructor is a decision the snippet has already made for you, and it was made for a codebase that is not yours.

So the practical workflow is to use the snippet to get the skeleton, then edit it. That is fine for a component you will touch anyway, and less fine for one that will be committed as generated, where a lint rule that the snippet does not satisfy will produce a diff on every file you create.

The repository has a CHANGELOG.md, which the README points to for the latest changes, and the extension is versioned 22.0.0 with the display name Angular Snippets (Version 22), so the catalogue and the Angular version are tied together in the version number itself.

A single author, a versioned catalogue and no releases

The maintenance picture is specific. The repository is not archived and the last push was on 2026-10-04, so the code is being worked on, and the README says the extension is updated for the Angular 22 release.

There are no GitHub releases, which for a VS Code extension is normal, since the marketplace listing is the distribution channel and the extension is versioned 22.0.0 in the manifest rather than by tag. The release process in the package scripts is just package, which runs vsce package, and publish, which runs vsce publish.

The interesting script is the third one. open-in-browser runs vscode-test-web with the extension development path, which means the extension can be exercised inside a browser based VS Code build rather than a desktop application. That is a genuine convenience for a snippet extension, since a snippet has no API surface that needs a real editor, and it means the test suite can run somewhere without a native VS Code install.

The test dependencies back that up, with @vscode/test-web and @types/vscode alongside typescript and the vsce packaging tool.

Who maintains it is the other thing an adopter should weigh. The package metadata names a single publisher, johnpapa, the licence file is LICENSE.md rather than a standard LICENSE, and the repository is a single person's project with an issue template, a pull request template, a code of conduct, an AGENTS.md and a devcontainer. It is popular and long lived, and it is also a project where the roadmap is one person's spare time, and where a catalogue entry can be right for Angular 22 and wrong for the version you are on.

Editorial conclusion

Adopt the Angular Snippets extension if you write Angular every day and the boilerplate for components, guards, services and interceptors is a tax you would rather not pay, and you are comfortable with generated code that you then edit. Do not adopt it as a scaffold for a project you intend to keep idiomatic, since the snippets encode one author's preferred structure, and do not expect it to track Angular automatically, because the catalogue is versioned against a named Angular release. Verify first that the version you install matches the Angular version in your project, that the snippet prefixes you rely on are the ones you think they are, and that the generated code passes your own linting rules before you commit it, because a snippet that produces a file your formatter reformats is a snippet you will edit every time.

Frequently asked questions

Official sources

1. Issues
2. johnpapa/vscode-angular-snippets on GitHub
3. License: MIT
4. README