Announcing Vendure v1.5
June 07, 2023
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)
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.
Chromaquery {
customers(options: { filter: { postalCode: { contains: "UP34"}}}) {
items {
id
firstName
lastName
addresses {
postalCode
}
}
}
}
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 }
}
}
}
Asset preview links
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 newRequestContext
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:
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)
fix(admin-ui): Correct the warning about the division in Sass (#1294)
chore: Enhance build.ts script for admin-ui-plugin (#1401)
fix(core): Fix for job cancellation issue (#1420)
docs(core): Fix doc for OrderItemPriceCalculationStrategy (#1430)
feat(core): Add order event (#1306)
feat(core): Add a job queue name prefix as a config option (#1359)
fix(admin-ui): Changes file name from ‘pt_PT’ to ‘pt’ to be compatible with Intl API
fix(core): Fix email verification for already-verified accounts (#1304)
fix(core): Fix PromotionActions not passing state correctly (#1323)
chore(core): Remove unused code, exported interfaces (#1436)
docs(core): Update jsdoc to address vendure-config/entityIdStrategy deprecation (#1348)
docs: Fix payments-plugin link in developer guide (#1368)
fix(payments-plugin): Mollie payment intent + Stripe unauthorized settlement fix (#1437)
docs: Add missing route parameter (#1452)
docs: Fix staticAssets path (#1455)
docs: Fix dead link (#1463)
Create your first commerce experience with Vendure in less than 2 minutes
Vendure is a registered trademark. Our trademark policy ensures that our brand and products are protected. Feel free to reach out if you have any questions about our trademarks.
Documentation
Newsletter
Get the latest product news and announcements delivered directly to your inbox.