An open-source headless commerce platform built on Node.js with GraphQL, Nest & TypeScript, with a focus on developer productivity and ease of customization.
- Getting Started: Get Vendure up and running locally in a matter of minutes with a single command
- Live Demo
- Vendure Discord: Join us on Discord for support and answers to your questions
master- The latest stable release, currently the 3.x series.minor- The next minor release, including new featuresmajor- The next major release (v4.0)v2.x- The 2.x line, which will receive critical fixes until the end-of-life on 31.12.2024. The code in this branch is under the MIT license.
This project is a monorepo managed with Lerna. Several npm packages are published from this repo, which can be found in the packages/ directory.
vendure/
├── docs/ # Documentation source
├── e2e-common/ # Shared config for package e2e tests
├── license/ # License information & CLA signature log
├── packages/ # Source for the Vendure server, admin-ui & core plugin packages
├── scripts/
├── changelog/ # Scripts used to generate the changelog based on the git history
├── codegen/ # Scripts used to generate TypeScript code from the GraphQL APIs
├── docs/ # Scripts used to generate documentation markdown from the source
Important
The following instructions are for those who want to develop the Vendure core framework or plugins (e.g. if you intend to make a pull request). For instructions on how to build a project using Vendure, please see the Getting Started guide.
npm install
The root directory has a package.json which contains build-related dependencies for tasks including:
- Building & deploying the docs
- Generating TypeScript types from the GraphQL schema
- Linting, formatting & testing tasks to run on git commit & push
npm run build
Packages must be built (i.e. TypeScript compiled, admin ui app built, certain assets copied etc.) before being used.
Note that this can take a few minutes.
All the necessary infrastructure is defined in the root docker-compose.yml file. At a minimum, you will need to start a database, for example:
docker-compose up -d mariadbMariaDB/MySQL is the default that will be used by the dev server if you don't explicitly set the DB environment variable.
If for example you are doing development on the Elasticsearch plugin, you will also need to start the Elasticsearch container:
docker-compose up -d elasticsearchVendure uses TypeORM, and officially supports MySQL, MariaDB, PostgreSQL and SQLite.
The first step is to populate the dev server with some test data:
cd packages/dev-server
[DB=mysql|postres|sqlite] npm run populateIf you do not specify the DB variable, it will default to "mysql". If you specifically want to develop against Postgres,
you need to run the postgres_16 container and then run DB=postgres npm run populate.
cd packages/dev-server
[DB=mysql|postgres|sqlite] npm run dev
If you are making changes to the admin ui, you need to start the admin ui independent from the dev-server:
cd packages/admin-uinpm run start- Go to http://localhost:4200 and log in with "superadmin", "superadmin"
This will auto restart when you make changes to the admin ui. You don't need this step when you just use the admin ui just to test backend changes.
This example shows how to test changes to the payments-plugin package locally, but it will also work for other packages.
- Open 2 terminal windows:
- Terminal 1 for watching and compiling the changes of the package you are developing
- Terminal 2 for running the dev-server
# Terminal 1
cd packages/payments-plugin
npm run watchcorepackage, you also need to watch the common package:
# Terminal 1
# Root of the project
npm run watch:core-common- After the changes in your package are compiled you have to stop and restart the dev-server:
# Terminal 2
cd packages/dev-server
DB=sqlite npm run dev- The dev-server will now have your local changes from the changed package.
To debug the dev server with VS Code use the include launch.json configuration.
graphql-code-generator is used to automatically create TypeScript interfaces for all GraphQL server operations and admin ui queries. These generated interfaces are used in both the admin ui and the server.
Running npm run codegen will generate the following files:
packages/common/src/generated-types.ts: Types, Inputs & resolver args relating to the Admin APIpackages/common/src/generated-shop-types.ts: Types, Inputs & resolver args relating to the Shop APIpackages/admin-ui/src/lib/core/src/common/generated-types.ts: Types & operations relating to the admin-ui queries & mutations.packages/admin-ui/src/lib/core/src/common/introspection-result.ts: Used by the Apollo ClientIntrospectionFragmentMatcherto correctly handle fragments in the Admin UI.- Also generates types used in e2e tests in those packages which feature e2e tests (core, elasticsearch-plugin, asset-server-plugin etc).
The core and several other packages have unit tests which are can be run all together by running npm run test from the root directory, or individually by running it from the package directory.
Unit tests are co-located with the files which they test, and have the suffix .spec.ts.
If you're getting Error: Bindings not found., please run npm rebuild @swc/core.
Certain packages have e2e tests, which are located at /packages/<name>/e2e/. All e2e tests can be run by running npm run e2e from the root directory, or individually by running it from the package directory.
e2e tests use the @vendure/testing package. For details of how the setup works, see the Testing docs.
When debugging e2e tests, set an environment variable E2E_DEBUG=true which will increase the global Jest timeout and allow you to step through the e2e tests without the tests automatically failing due to timeout.
All packages in this repo are released at every version change (using Lerna's fixed mode). This simplifies both the development (tracking multiple disparate versions is tough) and also the developer experience for users of the framework (it is simple to see that all packages are up-to-date and compatible).
To make a release:
It will run lerna publish which will prompt for which version to update to. Although we are using conventional commits, the version is not automatically being calculated from the commit messages. Therefore the next version should be manually selected.
Next it will build all packages to ensure the distributed files are up to date.
Finally, the command will create changelog entries for this release.
The reason we do not rely on Lerna to push the release to Git is that this repo has a lengthy pre-push hook which runs all tests and builds the admin ui. This long wait then invalidates the npm OTP and the publish will fail. So the solution is to publish first and then push.
See LICENSE.md.