angular-spotify names three Angular versions across three files, and shipped one release tag in 2021

Three Angular versions appear in three different files

The project description and the opening line both say Angular 15. The package manifest pins every Angular package at `17.3.2`, animations through forms through router through service worker, and the ngrx packages at `17.0.1`. A third number turns up in the share text embedded in the readme, which describes the project as made with Angular 12.

So the stack a reader is told about and the stack the lockfile will install are two majors apart, and a third number survives in a link that nobody updates. Nothing in the repository reconciles them, and the readme does not mention the upgrade.

The rest of the manifest is more precise than the prose about it. Angular packages are pinned to an exact patch rather than a caret range, which is deliberate for a teaching repository, since a range would let a reader install something the code was never run against. The ngrx set covers store, effects, component, and component-store, and there is an Ant Design icon package and a colour library alongside the two ngneat packages.

One detail worth noting for a project meant to teach Nx: the readme calls out its store usage as an experiment rather than a recommendation, which is discussed separately below.

One release tag from 2021, a branch pushed in 2026

The release list has a single entry, v1.0, dated 2021-03-29. The branch itself was last pushed on 2026-08-14. That is the whole picture of this project's shipping history: one tag, and five years of commits after it.

The manifest version field says `1.0.0`, which is consistent with the tag rather than with anything newer, so nothing in the repository suggests the work since then was ever released in a form you could install.

That is not unusual for an application repository, since there is nothing to consume here, but it matters if you are reading this as a reference implementation rather than as a product. The interesting material, the workspace layout, the store usage, and the authentication migration, all of it lives on the branch and none of it is versioned.

The deployment target is Netlify, and there is a live application at the author's own domain, so the branch is not dormant in the sense of not working. What it is not is pinned.

Access and refresh tokens sit in browser local storage

The authentication section is the most concrete part of the documentation. On opening the application it redirects to Spotify for access. The author states the application uses the returned data purely for display in the interface and stores nothing anywhere else, and then describes exactly where the credentials go: the access token and the refresh token are stored in browser local storage. Access tokens are valid for one hour and are refreshed automatically with the refresh token when they expire.

After the tokens are in place, the application connects to the Web Playback SDK with a player component, which is what actually plays audio in the page.

Local storage is the choice to think about. It is readable by any script running on the same origin, and it survives a browser restart, so a token there persists longer than the hour it is valid for. The refresh token is the sensitive half, because it is what mints new access tokens. For a personal client on your own machine that may be an acceptable trade, and for anything embedded in a shared origin it is the thing to change first.

The refresh flow is the mitigation the project already implements, since the one hour expiry is handled for you rather than logging you out.

The implicit grant flow was sunset, so the app moved to PKCE

There is a migration notice at the top of the authentication section, and it is dated. The application previously used the Implicit Grant Flow, which Spotify will sunset on November 27, 2025. It has been migrated to Authorization Code with PKCE, which is the approach Spotify recommends for client-side applications that have no secret keys.

The stated reasons are the standard ones: better security than the deprecated flow, and refresh tokens included, so access extends when the access token expires. Two links are given for the Spotify authorisation guide and for the PKCE tutorial.

That deadline has now passed, which turns this from a note into a constraint. A client that had not migrated by then would simply stop working against the API, so the code on the branch is the only version worth reading, and the old flow is not something you can reinstate.

The flow itself has one structural implication for anyone deploying a copy. Because there is no secret key in a browser application, the redirect and the allowed origins are configured on the Spotify application side rather than in the code, so a fork needs its own client registration and its own settings before it will authenticate at all.

The author calls his own store usage an experiment to be refactored

One paragraph is worth quoting rather than paraphrasing, because it is the kind of admission most example repositories leave out. The author says he experimented with the ngrx component store for the authentication store and the UI store, that it might not be a best practice, and that he will refactor it soon.

The same honesty runs through the principles section. The stated rule is that components use OnPush change detection with async pipes, rendering data from observables without a single manual subscribe, and that only some places call subscribe in order to dispatch an action. There is a named plan to refactor those into the component store for a fully subscribe-less application, worked on with another author, and the note that it is not done yet.

So the two stores to look at first, the auth store and the UI store, are the two the author flags. That is useful information if you are reading the code to learn the pattern, and a warning if you were going to copy the store layer wholesale.

The pattern the author does recommend is that almost everything lives under `libs` rather than `apps`, which is the next thing worth looking at.

One module per component, and everything shared lives in libs

The architecture section states three principles. The first is OnPush with async pipes, covered above. The second is single component Angular modules for tree-shakable components: each component has its own module, so a register component has a register module, and that component is deliberately not declared as part of an auth module. The stated reason is tree-shaking.

The third principle is about where files live. New modules, models, configurations, and components all go in the `libs` folder rather than in `apps`, and `libs` is subdivided by which existing app uses them.

The directory map that follows makes the shape concrete without being large. Under the root there are `apps`, holding the single application, and `libs`, holding a `web` directory. Inside that sit feature areas such as `shell`, `settings`, and `playlist`, each with subdirectories whose roles are annotated in the map itself: a `feature` library for configuring root modules, a `data-access` library for stores and services, and a `ui/layout` library for the layout components.

The annotations also record which kind of Nx project each directory is, an Angular library or a workspace library, which is the distinction that trips people up when they first meet Nx.

Husky, lint-staged, commitlint and jest, with no setup instructions anywhere

The tooling in the tree is thorough and the instructions are not. A Husky directory, a lint-staged configuration, and a commitlint configuration sit at the root together with a postinstall script that installs the Husky hooks, so commit messages and staged files are both checked. Jest appears as a config file and a preset at the root. There is an Nx migrations file, an editor config, an ESLint config with its own ignore file, Prettier with separate ignore and config files, and an editor ignore file listing the Node version.

What is missing is any way to run it. There is no clone instruction, no install command, and no explanation of how to supply your own Spotify client credentials, which the authentication section implies you need and the readme never says where to put.

The scripts themselves are a full Nx surface, including the affected commands with a base of `main`, a format write that also takes that base, a migrate command, and a generator for icons. Two of them use flags that have been superseded in newer Nx versions, the `--prod` flag on the production build and the workspace lint command, which is consistent with a project whose last release tag is from 2021.

A live application is linked, so the quickest way to see the stack in motion is to watch it rather than to build it.

Editorial conclusion

This suits a developer who wants to read a large Angular codebase organised the way an Nx workspace is meant to be organised, and who already has a Spotify account and a browser to try it in. It does not suit a production starting point: the version story is inconsistent, the project says its own store usage needs refactoring, and playback needs a paid Spotify account. Before you fork it, check three things: which Angular version you will actually build with against the pinned 17.3.2 packages, what your Spotify application's own authorising redirect settings need to be, and whether you are willing to hold refresh tokens in browser local storage, which is what this implementation does.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. trungvose/angular-spotify on GitHub