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 🙏

© 2024 – Pkg Stats / Ryan Hefner

gseller

v1.0.0

Published

An open-source headless commerce platform built on [Node.js](https://nodejs.org) with [GraphQL](https://graphql.org/), [Nest](https://nestjs.com/) & [TypeScript](http://www.typescriptlang.org/), with a focus on developer productivity and ease of customiza

Downloads

1

Readme

Vendure

An open-source headless commerce platform built on Node.js with GraphQL, Nest & TypeScript, with a focus on developer productivity and ease of customization.

Build Status Publish & Install lerna

www.vendure.io

Branches

  • master - The latest stable release, currently the 2.x series.
  • minor - The next patch release, including new features
  • major - The next major release (v3.0)
  • v1 - The 1.x series, which is no longer actively developed but may still receive critical fixes.

Structure

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
├── packages/       # Source for the Vendure server, admin-ui & 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

Development

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.

1. Install top-level dependencies

yarn

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

Note: When you do yarn for the first time, you will need to manually create the package folder under /packages/admin-ui.

2. Bootstrap the packages

yarn bootstrap

This runs the Lerna "bootstrap" command, which cross-links monorepo dependencies.

3. Build all packages

yarn 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.

4. Set up the server

The server requires an SQL database to be available. The simplest option is to use SQLite, but if you have Docker available you can use the dev-server docker-compose file which will start up both MariaDB and Postgres as well as their GUI management tools.

Vendure uses TypeORM, and officially supports MySQL, PostgreSQL and SQLite, though other TypeORM-supported databases may work.

  1. Configure the dev config, making sure the connection settings in the getDbConfig() function are correct for the database type you will be using.
  2. Create the database using your DB admin tool of choice (e.g. phpMyAdmin if you are using the docker image suggested above). Name it according to the getDbConfig() settings. If you are using SQLite, you can skip this step.
  3. Populate mock data:
     cd packages/dev-server
     DB=<mysql|postgres|sqlite> yarn populate
    If you do not specify the DB variable, it will default to "mysql".

5. Run the dev server

cd packages/dev-server
DB=<mysql|postgres|sqlite> yarn start

Or if you are in the root package

DB=<mysql|postgres|sqlite> yarn dev-server:start

If you do not specify the DB argument, it will default to "mysql".

Testing admin ui changes locally

If you are making changes to the admin ui, you need to start the admin ui independent from the dev-server:

  1. cd packages/admin-ui
  2. yarn start
  3. 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.

Testing your changes locally

This example shows how to test changes to the payments-plugin package locally, but it will also work for other packages.

  1. 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
yarn watch

:warning: If you are developing changes for the corepackage, you also need to watch the common package:

# Terminal 1
# Root of the project
yarn watch:core-common
  1. 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 yarn start
  1. The dev-server will now have your local changes from the changed package.

:information_source: Lerna links to the dist folder of the packages, so you don't need to rerun 'yarn bootstrap'

Code generation

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 yarn codegen will generate the following files:

Testing

Server Unit Tests

The core and several other packages have unit tests which are can be run all together by running yarn 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.

End-to-end Tests

Certain packages have e2e tests, which are located at /packages/<name>/e2e/. All e2e tests can be run by running yarn e2e from the root directory, or individually by running it from the package directory.

e2e tests use the @gseller/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.

Release Process

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:

1. yarn publish-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.

2. git push origin master --follow-tags

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.

License

MIT