🚨 Announcement: A New Chapter for Vendure read more

← Back to the blog

Announcing Vendure v1.5

Author avatar
March 15, 2022
Michael Bromley
@michlbrmly

Version 1.5 of the open-source headless commerce framework Vendure is available now! This release sees Vendure reach a point of high stability & maturity, with all major APIs completed and almost a year of bug fixes and refinements behind us. In this post I’ll cover the main new features in this release, and then briefly outline plans for the next major version: Vendure 2.0.

Video sections: security features (34s), modify coupon codes (2m 01s), asset preview links (3m), generic relation input (3m41s), custom refund reasons (4m55s), filter by postal code (5m54s), Stripe integration (6m 18s), Vendure 2.0 roadmap (7m 11s)

v1.5.0 Changelog

Upgrading from v1.x.x

This minor release contains no breaking schema or GraphQL API changes (except for the Mollie Plugin - see later secion), so updating should be a matter of changing all @vendure/... dependencies in your package.json file to 1.5.0.

{
  "dependencies": {
-    "@vendure/admin-ui-plugin": "1.4.7",
-    "@vendure/asset-server-plugin": "1.4.7",
-    "@vendure/core": "1.4.7",
-    ... etc
+    "@vendure/admin-ui-plugin": "1.5.0",
+    "@vendure/asset-server-plugin": "1.5.0",
+    "@vendure/core": "1.5.0",
+    ... etc
  },
  "devDependencies": {
-    "@vendure/testing": "1.4.7", 
+    "@vendure/testing": "1.5.0",
  }
}

Also see the Updating Vendure guide for more information.

Stripe integration

In Vendure 1.4 we introduced the payments plugin, adding support for Mollie and Braintree. Now I’m happy to announce our next and much-requested payment integration - Stripe!

Stripe is one of the most popular payment providers, offering a suite of payment services in over 135 currencies & payment methods. This integration was built by Vendure community member Vinicius Rosa, and is designed to work with Stripe’s custom payments flow. Get started with Stripe in our new StripePlugin docs!

New security features

This release introduces the new PasswordValidationStrategy, which allows you to define a function to validate a new password when creating a new Customer or Administrator account. This allows you, for example, to enforce a policy of “minimum 8 characters, including at least one special character”. By default, the validation is permissive in order to preserve backwards-compatibility, but you can set your own, stricter strategy in apiOptions.passwordValidationStrategy.

const config = {
  authOptions: {
    passwordValidationStrategy: new DefaultPasswordValidationStrategy({
      // Minimum eight characters, at least one letter and one number
      regexp: /^(?=.*[A-Za-z])(?=.*\d)[A-Za-z\d]{8,}$/,
    }),
  }
}

Another important new security feature is the ability to disable introspection of the GraphQL APIs. To find out why you might want to do this, read Why You Should Disable GraphQL Introspection In Production from the Apollo blog. To disable introspection, set apiOptions.introspection to false.

Modifying order coupon codes

When modifying an existing Order, you can now add or remove coupon codes. This allows you to apply or remove Promotions after an Order has been placed. Since changes to the applied Promotions will result in a change in the Order total, the Order modification flow will also account for automatic refunds as well as the ability to add additional payments.

List filtering improvements

The customers query can now be filtered by postalCode, which allows you to quickly find Customers based on their addresses - a very common requirement in real-world useage. The Admin UI has also been updated with a filter input for postal code.

query {
  customers(options: { filter: { postalCode: { contains: "UP34"}}}) {
    items {
      id
      firstName
      lastName
      addresses {
        postalCode
      }
    }
  }
}
{
  "data": {
    "customers": {
      "items": [
        {
          "id": "8",
          "firstName": "Alec",
          "lastName": "Breitenberg",
          "addresses": [
            {
              "postalCode": "UP34 8TT"
            }
          ]
        }
      ]
    }
  }
}

Custom field list types can now be filtered using the new inList filter operator. This operator takes a single value, and then returns entities which contain that value in the list.

query {
  products(options: { filter: { keywords: { inList: "ssd" } } }) {
    items {
      id
      name
      customFields { keywords }
    }
  }
}
{
  "data": {
    "products": {
      "items": [
        {
          "id": "1",
          "name": "Laptop",
          "customFields": {
            "keywords": [
              "4k",
              "ssd",
              "intel"
            ]
          }
        },
        {
          "id": "8",
          "name": "Hard Drive",
          "customFields": {
            "keywords": [
              "ssd",
              "gaming"
            ]
          }
        }
      ]
    }
  }
}

You can now easily access preview urls of Assets using the new “asset preview links” menu:

Generic custom field relation input

When you define a custom field of type relation, the Vendure Admin UI will attempt to pick a suitable input control. Currently there are built-in input controls for relations to Asset, Product and ProductVariant entities. But what happens if your custom field relation is some other entity, for example ShippingMethod? Previously, the Admin UI would just display a message that read “No input component configured for ShippingMethod type”, and you’d be forced to implement a custom form input.

With v1.5, we now ship a generic relation form input which works with relations to any entity. It allows you to specify the ID manually, and takes care of the rest.

Other notable featuers

  • The default refund reasons when refunding and/or cancelling an Order can now be configured using the new cancellationReasons property in the AdminUiConfig:
    AdminUiPlugin.init({
      route: 'admin',
      port: 5001,
      adminUiConfig: {
        cancellationReasons: [`custom reason 1`, `custom reason 2`],
      },
    }),
    
  • New events have been added to allow you to subscribe and react to changes to Orders. First, the OrderEvent will be published whenever an Order is created or has its custom fields updated. Then the OrderLineEvent allows you to react when a new OrderLine is added, updated or removed.
  • The RequestContextService is now exposed and documented, and includes a new create() method which allows you to easily create new RequestContext instances when one is not already available.
  • All of the internal services used to populate data are now exposed publicly. In addition, it is now possible to specify a specific Channel when using the populate function.
  • It is now possible to delete Customer addresses via the Admin UI from the Customer detail page.

Breaking change in Mollie Plugin

The Mollie Plugin has been re-worked to handle a problem with the existing workflow which could result in Orders getting stuck in a PaymentAuthorized state and being unable to be processed further (see issue #1330). The solution to this issue required that the storefront payment flow be re-designed. Since this is quite a critical issue, we took the decision to introduce the necessary breaking change now rather than wait until v2.0.

Please see the updated MolliePlugin documentation to see how your storefront code should now look with these changes.

Towards Vendure v2.0

Finally, let’s talk about the next major version of Vendure. It has now been around 10 months since the release of Vendure v1.0. In that time, we’ve had 26 updates introducing new features, fixing bugs, and improving performance. I can now confidently say that Vendure is a mature, proven and production-ready headless commerce platform.

So what’s next? Well, there are a number of changes and features I’d like to introduce which I cannot, since they would require breaking changes. I try my best to follow semantic versioning, which means that all v1.x.x releases should be backwards-compatible. In other words, updating the Vendure package versions should not require any changes to your existing code. So far we’ve done a pretty good job of this!

However, certain changes simply cannot be made without changing the database schema, updating dependent libraries with breaking API changes, or altering parts of the Vendure data model. Here are some examples of breaking changes which need to wait until v2.0:

  • Updating the underlying libraries that Vendure is built on to their latest versions, namely NestJS, GraphQL, Apollo Server & Angular.
  • Modifying the data model to support multiple stock locations.
  • Adding support for bundle products (allowing custom products to be assembed from disparate ProductVariants)
  • Improving support for true multivendor marketplaces - this will be a major focus of the next version, since there is huge demand for it and there seems to be very few alternatives out there at present. If you are interested in this feature, I invite you to share ideas & feedback in this issue.
  • Removing deprecated APIs.

All of the above and more are planned for Vendure v2.0. You can see the status of these issues in our roadmap.

It is also possible to start testing these changes now by using the @next tag:

npm install @vendure/core@next

This will install a version like 2.0.0-next.1, which reflects the major branch of the Vendure repo. Changes in these pre-release versions can be found in the CHANGELOG_NEXT.md file. I’m using the @next version in my own Vendure projects, but the usual caveats about using pre-release software apply!

I have no set timeline fo the release of v2.0, but I would expect it to be ready within the next six months 🤞.

Thank you to all contributors

I’d like to thank the wonderful Vendure community who contribute their ideas, bug reports, and code to the project daily. This release includes code contributions by:

  • Alexander Shitikov:
    • refactor(core): Allow to mock self-refreshing cache for channel and zones (#1373)
    • feat(admin-ui): Allow custom ng compiler args to be passed to admin ui compiler (#1386)
    • fix(core): Support usage of GQL interfaces on relational custom field (#1460)
  • Alexis Vigoureux:
    • fix(admin-ui): Correct the warning about the division in Sass (#1294)
  • Amadeus Alfa:
    • chore: Enhance build.ts script for admin-ui-plugin (#1401)
  • Balazs Gallay:
    • fix(core): Fix for job cancellation issue (#1420)
  • Christophe Blin:
    • docs(core): Fix doc for OrderItemPriceCalculationStrategy (#1430)
  • David Spiessens:
    • feat(core): Add order event (#1306)
  • Dushko Jordanovski:
    • feat(core): Add a job queue name prefix as a config option (#1359)
  • Filipe Moraes:
    • fix(admin-ui): Changes file name from ‘pt_PT’ to ‘pt’ to be compatible with Intl API
  • Harun Kilic:
    • fix(core): Fix email verification for already-verified accounts (#1304)
  • Hubert Zub:
    • fix(core): Fix PromotionActions not passing state correctly (#1323)
    • chore(core): Remove unused code, exported interfaces (#1436)
  • Josh McCulloch:
    • docs(core): Update jsdoc to address vendure-config/entityIdStrategy deprecation (#1348)
  • Kal Abdi:
    • docs: Fix payments-plugin link in developer guide (#1368)
  • Martijn van de Brug:
    • fix(payments-plugin): Mollie payment intent + Stripe unauthorized settlement fix (#1437)
  • Martin Repta:
    • docs: Add missing route parameter (#1452)
    • docs: Fix staticAssets path (#1455)
    • docs: Fix dead link (#1463)
Author avatar
Written by
Michael Bromley
Michael is the creator of Vendure. He lives in Vienna, Austria.
Twitter logo GitHub logo