# lwc-recipes: a working reference for Salesforce Lightning Web Components

> trailheadapps/lwc-recipes is a sample Salesforce application whose components double as short, copyable examples. It is a learning and reference repository, not a library you install into a product.

**trailheadapps/lwc-recipes** — A collection of easy-to-digest code examples for Lightning Web Components on Salesforce Platform

- Repository: https://github.com/trailheadapps/lwc-recipes
- Website: https://developer.salesforce.com
- Stars: 2,891 · Forks: 3,251
- Language: JavaScript
- License: CC0-1.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/trailheadapps-lwc-recipes

## What lwc-recipes is, and the problem it removes

Lightning Web Components ship with a lot of small questions attached. How do you wire an Apex method, how do you call an imperative Apex method, how do you pull in a third-party library, how do you test a component with Jest. The official documentation answers these in prose. lwc-recipes answers them in code. The README describes the project as "a collection of easy-to-digest code examples for Lightning Web Components", where each recipe "demonstrates how to code a specific task in the fewest lines of code possible while following best practices".

The audience is narrow and clearly stated. The README says the sample application "is designed to run on Salesforce Platform", and it points readers who want Lightning Web Components on any platform to lwc.dev and to a separate repository, LWC Recipes OSS. That split matters. If you are not on Salesforce, this repository is the wrong starting point, and the README says so itself.

The intended workflow is browsing rather than reading. Each recipe carries a "View Source" link that takes you to the code on GitHub, so the app in your org and the source in the repository are meant to be looked at together.

## How the recipes are organised inside the repository

The repository is a Salesforce DX project. The top level holds the metadata that makes that true: sfdx-project.json, config/ with the scratch org definition, force-app/ with the source, and data/ with the sample records. Around that sit the JavaScript tooling files: package.json, eslint.config.js, jest.config.js, jest-sa11y-setup.js and a Prettier configuration.

That layout tells you what the project actually is: an org metadata bundle plus a Node test harness. The recipes themselves live under force-app/, and the tests that ship with them run through sfdx-lwc-jest, the Salesforce Jest preset listed in devDependencies. Accessibility checks come from @sa11y/jest, also in devDependencies. So a recipe is not just a component; it is a component, its Jest test, and the lint rules that apply to it.

The package.json scripts show the intended local loop. lint runs eslint, test:unit runs sfdx-lwc-jest, and test:unit:coverage adds coverage. A lint-staged block runs Prettier, ESLint and related Jest tests on staged files, which is why husky appears as a devDependency. The repository is wired to keep its own examples consistent.

## Installing lwc-recipes into a scratch org

The README calls the scratch org route the recommended installation option, for developers who want to experience the app and the code. It assumes you have already completed the Quick Start: Lightning Web Components Trailhead project, which covers enabling Dev Hub, installing the Salesforce CLI, installing Visual Studio Code, and installing the Salesforce extensions.

First authorize your hub org. The -d flag makes it the default, and the alias is myhuborg in the README's example.

```bash
sf org login web -d -a myhuborg
```

Then clone the repository and create a scratch org from the definition file in config/. The alias here is lwc-recipes.

```bash
sf org create scratch -d -f config/project-scratch-def.json -a lwc-recipes
```

Push the source, assign the recipes permission set, and import the sample data from the data plan.

```bash
sf project deploy start
sf org assign permset -n recipes
sf data tree import -p ./data/data-plan.json
```

Open the org with sf org open. Two steps remain and they are easy to miss because they happen in the UI rather than the terminal. In Setup, under Themes and Branding, activate the Recipes Lite or Recipes Blue theme. Then in App Launcher, click View All and select the LWC app. What you should see after that is the recipe app with its sample accounts and contacts populated.

## The unlocked package route and the Developer Edition route

Not everyone wants a local toolchain. The README offers an unlocked package for exactly that case, aimed at non source-tracked orgs such as a free Developer Edition Org or a Trailhead Playground. You install it by following a login.salesforce.com packaging link in the README and selecting Install for All Users. There is no CLI command for this path.

Data import is manual on this route. You download Accounts-Contacts.csv from the repository's raw URL, then use Setup, Data Import Wizard, choose Accounts and Contacts, Add New Records, and upload the file. The README notes that assigning the recipes permission set is required only if you are attempting the Quick Start Trailhead project, and otherwise can be skipped.

The third route, a Developer Edition org or Trailhead Playground with a local checkout, is a middle ground: clone the repository, authorize the org with sf org login web -s -a mydevorg, then deploy with sf project deploy start -d force-app. The -d flag limits the deploy to that directory. The README repeats its warning for both non-scratch routes: start from a brand-new environment to avoid conflicts with previous work.

That warning is the most practically important line in the installation section. Deploying a sample app into an org that already has custom objects, permission sets or themes is where people get into trouble.

## Where lwc-recipes stops being the right tool

The repository is a teaching artefact, and its own packaging reflects that. The package.json sets "private": true and the version is 0.1.0. You cannot publish it, and nothing in the repository suggests it is intended as a dependency. Copying a recipe into your own component is the normal use; adding the repository to a build is not.

The scratch org definition is a second boundary. It lives in config/project-scratch-def.json and describes one particular org shape. If your target org differs, the deploy may succeed while the app still misbehaves, because the recipes assume the features that definition enables.

There is also a scope limit that the README states plainly rather than hides. This is a Salesforce Platform sample. Teams running Lightning Web Components outside Salesforce are directed to LWC Recipes OSS instead, and the two repositories are not interchangeable. Finally, the repository has no releases listed, so there is no versioned artefact to pin against. You track the main branch or you use the unlocked package link, and neither gives you a changelog to diff when something shifts.

## lwc-recipes against LWC Recipes OSS

The only alternative the README names is LWC Recipes OSS, and the difference is where the components run. lwc-recipes targets the Salesforce Platform: its recipes deploy as org metadata, its data comes from a Salesforce data plan, and its access model runs through a permission set named recipes. LWC Recipes OSS targets Lightning Web Components as an open source framework, so its components stand alone without an org behind them.

That changes what a recipe can demonstrate. A Salesforce-hosted recipe can show a wired Apex method returning records, because there is an org to answer the call. An OSS recipe cannot, because there is no Apex runtime. Conversely, the OSS repository is the one the README recommends if you want to "experience Lightning Web Components on any platform".

If your work is Salesforce development, the split rarely matters: lwc-recipes is the one whose patterns transfer. If you are evaluating LWC as a general front-end framework, the Salesforce-specific recipes are the wrong reference and the README's own redirect is the correct one to follow.

## Licence and the cost of keeping up

The repository is licensed CC0-1.0, which is a public domain dedication rather than a permissive software licence. In practice that is unusually generous for sample code: there is no attribution requirement and no copyleft obligation attached to the recipes themselves. This is a description of the licence identifier, not legal advice, and it covers the repository contents rather than the Salesforce Platform your org runs on.

The maintenance picture is favourable but should be read carefully. The repository is not archived, and the last push was on 2026-09-09, which is recent. That is a fact about commit activity, not a promise about support. There are no releases in the repository, so there is no upgrade path in the usual sense: you re-clone or re-deploy and take whatever changed.

Upgrade cost is mostly local. Because the recipes are copied rather than imported, an upstream change does not reach your org unless you go and fetch it. The costs that do accumulate are the tooling ones: the devDependencies pin ESLint, Prettier, sfdx-lwc-jest and @sa11y/jest, and those move independently of the recipes. If you adopt the Jest setup for your own components, that dependency set becomes yours to maintain.

## Conclusion

Adopt lwc-recipes if you are learning Lightning Web Components on the Salesforce Platform or need a known-good pattern for a specific task such as calling Apex or importing sample data. Do not adopt it as a dependency: it is a sample app, not a package you build on, and the README points anyone wanting LWC outside Salesforce to lwc-recipes-oss instead. Before you rely on a recipe, check that its pattern still matches your API version and that the component is not built around a specific org feature, then run npm run test:unit locally to see the Jest setup work.

## FAQ

### What does LWC stand for?

LWC stands for Lightning Web Components, the component model this repository is built around. The README describes lwc-recipes as a collection of easy-to-digest code examples for Lightning Web Components, each demonstrating a specific task in the fewest lines possible.

### What is LWC used for?

Lightning Web Components are used to build components that run on the Salesforce Platform, and lwc-recipes shows how to do that for tasks such as data access, calling Apex and using third-party libraries. The README states the sample application is designed to run on Salesforce Platform.

### What is the difference between LWC and Aura?

The repository does not explain the difference between the two frameworks. Its devDependencies include @salesforce/eslint-plugin-aura, so Aura lint rules are present in the tooling, but the README does not describe how Aura and LWC compare.

### How long will it take to learn LWC?

The repository does not give a learning timeline. The README does point to the Quick Start: Explore the LWC Recipes Sample App Trailhead project and a short presentation video as ways to learn the app, and each recipe includes a View Source link to the code on GitHub.

## Sources

- [Issues](https://github.com/trailheadapps/lwc-recipes/issues)
- [License: CC0-1.0](https://github.com/trailheadapps/lwc-recipes/blob/main/LICENSE)
- [Project website](https://developer.salesforce.com)
- [README](https://github.com/trailheadapps/lwc-recipes/blob/main/README.md)
- [trailheadapps/lwc-recipes on GitHub](https://github.com/trailheadapps/lwc-recipes)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/trailheadapps-lwc-recipes