Skip to main content

project news

Node.js 21 Available Now!

By Announcement, Blog, Node.js

The release of Node.js 21 is available now! Node.js 21 replaces Node.js 20 as our current release line, and Node.js 20 is being promoted to long-term support (LTS). 

What’s the difference between the two releases? Node.js 21 is great for early feature testing for your own specific environment, while Node.js 20 LTS is for production deployments. Node.js 21 will be ‘Current’ release for the next 6 months, until April 2024. Here is our full Node.js release schedule.

​​Highlights in Node.js 21 include updates of the V8 JavaScript engine to 11.8, stable WebStreams, a new experimental flag to flip module defaults (–experimental-default-type), many updates to our test runner, and more!

“If you’re interested in getting access to interesting new features early, Node.js 21 is a great way to test and see what’s coming. Our release schedule specifically covers this. If you’re already in active deployment or if you are planning for it, Node.js 20 and 18 LTS are for you,” said Rafael Gonzaga, Node.js Technical Steering Committee (TSC) Member. “Many thanks to our open source contributors for making Node.js better and better. Thanks also to OpenSSF and Project Alpha Omega for helping us improve Node.js security.”

“Node.js demand among developers continues to grow as the need for reliable and scalable web applications rises. With Node.js 21, you can evaluate the current state of Node.js features directly,” said Michaël Zasso, member of the Node.js TSC. “As just one example, Node.js has had a stable test runner since Node.js 20. There’s no need to install a third-party module, and you can create test scripts easily. Node.js 21 includes many improvements to the test runner. Try it out!” 

Main updates for Node.js 21

  • V8 JavaScript engine updated to 11.8
  • Stable WebStreams which helps to process data in small sizes for browser applications
  • A new experimental flag to flip module defaults (–experimental-default-type) – Node.js has two module systems: CommonJS modules and ECMAScript modules. Node.js treats files with a .js extension by default as CommonJS modules. This can now more easily be flipped.
  • Many updates to test runner which allows users to run functional tests and export results
  • Full changes and commits here

Download Node.js 21 here and get started testing right away! More details can be found in the Node.js blog.

JSON Schema Joins OpenJS Foundation

By Announcement, Blog, Project Update

JSON Schema is the newest technical project hosted under the OpenJS Foundation! 

JSON Schema is a vocabulary that allows you to annotate and validate JSON documents. It defines how a JSON should be structured, making it easy to ensure that a JSON is formatted correctly, and it is useful for automated testing and validating. In addition, JSON Schema provides clear human- and machine-readable documentation.

“We are thrilled to welcome JSON Schema into the OpenJS Foundation. Building a community requires dedicated people and great technology, which JSON Schema already has. It also requires a reliable structure for open governance and legal support that allows worldwide communities to grow. As the vendor-neutral home to almost 40 open source projects, JSON Schema already fits in well with our ecosystem of projects,” said Robin Ginn, OpenJS Foundation executive director. “We look forward to providing resources and support to JSON Schema to help their community to grow.”

“JSON Schema’s supportive community has in part enabled us to get this far. This has been critical to its success. JSON Schema is primarily a validation tool, plus it’s gaining additional uses such as generating forms, generating databases, or generating other UIs. We want to make sure the community and technology can continue to grow, possibly in unforeseen directions,” said Ben Hutton, JSON Schema specification lead at Postman. “By joining the OpenJS Foundation, we gain the community structure and support – with a strong focus on open governance – to continue to build and enlarge the community. We remain committed to being an interoperability focused standard, and want to provide assurance that JSON Schema will remain open and owned by the community that needs it.”

“The OpenJS Foundation continues to grow, and JSON Schema is a great addition. It is a key foundational technology, and by joining the OpenJS Foundation, it now has a strong home for further growth,” said Todd Moore, OpenJS Foundation Board Chairperson and Chief Developer Advocate IBM. “We are looking forward to working with and supporting JSON Schema.”

“The OpenJS Foundation is continuing to support key technologies that JavaScript communities rely upon. JSON Schema is an important addition,” said Joe Sepi, Open Source Program Director at IBM, and chairperson of the OpenJS Foundation Cross Project Council.“ JSON Schema is a great example of how interconnected JavaScript technologies can be. Providing a structure for sharing data is critical.”

“The Cross Project Council carefully considers the projects that join our neutral home at the OpenJS Foundation. We are pleased to have JSON Schema onboard so we can support the project’s growth, and the maintainers can contribute their expertise to the broader JavaScript ecosystem through OpenJS,” said Eemeli Aro, Staff Software Engineer at Mozilla, and OpenJS Cross Project Council (CPC) member. 

JSON Schema will be designated “At-Large,” which includes many different types of projects but is most often used for stable projects with minimal needs. They are now officially in the incubation process where projects complete their on-boarding to join the foundation.

To find out more about JSON Schema, including a complete list of current implementations, see 

JSON Schema Resources


OpenJS Resources

Click here to learn more about how you could be a part of the OpenJS Foundation, and view these additional resources:


About OpenJS Foundation

The OpenJS Foundation is committed to supporting the healthy growth of the JavaScript ecosystem and web technologies by providing a neutral organization to host and sustain projects and collaboratively fund activities for the benefit of the community at large. The OpenJS Foundation is currently home to 35 open source JavaScript projects, including Appium, Dojo, jQuery, Node.js, and webpack. It is supported by 30 corporate and end-user members, including GoDaddy, Google, IBM, Intel, Joyent, and Microsoft. These members recognize the interconnected nature of the JavaScript ecosystem and the importance of providing a central home for projects which represent significant shared value. 

About Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1000 members and is the world’s leading home for collaboration on open source software, open standards, and open hardware. Linux Foundation projects like Linux, Kubernetes, Node.js, and more are considered critical to developing the world’s most important infrastructure. Its development methodology leverages established best practices and addresses the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit their website.


Streamlining contributions for OpenJS Foundation projects with new CLA infrastructure

By Blog

The OpenJS Foundation team has been busy helping several projects migrate to new CLA tooling. OpenJS has adopted the EasyCLA bot, developed by the Linux Foundation, as its choice for IPR assurance on projects that elect to use a CLA. This work has been part of ongoing, overall infrastructure improvements to improve long-term maintainability for projects.

EasyCLA balances the need to provide a friction-free solution for developers as well as a robust, auditable solution for corporate open source program offices. With the new tool, companies will be able to authorize contributions across all our projects, not just on a project-by-project basis, and authorize entire teams or email domains at once. Projects such as jQuery, ESLint,, and Webpack have already been transitioned to this new infrastructure, with the rest to follow soon.

OpenJS Foundation’s IPR policy allows projects to select either a DCO or CLA for contribution agreements. Projects that have elected the DCO, such as Node.js, are not affected by this change. Interested parties can read more about the tools and policies on our repo,


Does everyone have to re-sign the CLA with this bot, or does my old signature transfer?

Yes, everyone will need to re-sign the CLA with the EasyCLA tool for any future contributions. Fortunately many corporate contributors will find that their organization has already signed our CLA, and signing the CLA as an individual is quite straightforward. If you have previously signed the CLA with the JS Foundation bot, that signature still covers your past contributions. You can read the text of the Individual CLA prior to signing here. Companies can read the text of the Corporate CLA prior to signing here.

I am contributing to OpenJS Foundation projects on behalf of my company. What do I need to know?

An authorized signer for your company will need to execute our corporate CLA before you can contribute, if they have not already done so. Your company’s signatory will also name one or more persons to serve as CLA Managers – people authorized by the company to permit contributions on its behalf. You can start that process yourself when you open a pull request and select ‘Corporate Contribution’, or you can request staff assistance to help onboard your organization. 

Why is this happening now?

Simply put, the old CLA infrastructure that supported some JS Foundation projects has stopped working and is likely not coming back. We were already in the process of migrating projects, but this has accelerated the timeline. Unfortunately it is not an option to remain on the old CLA bot, as the mandatory CLA checks on open PRs will never return.

My PR was open before the transition to EasyCLA, and I still have an outstanding JS Foundation CLA check – what do I do?

A small number of PRs may be caught between the two CLA checking tools because they were already open during the switch. In this case, you will see a check for both EasyCLA and `license/cla` on the same PR, and furthermore, that `license/cla` is permanently yellow. In the very specific case where the EasyCLA check is passing and `license/cla` is the only failing check, maintainers may bypass the failing `license/cla` check. If you are sure you have signed EasyCLA but do not see the check passing, you can trigger a recheck by typing /easycla in a comment on the PR or by closing, then re-opening, the PR.

LoopBack Joins OpenJS Foundation As New Incubating Project

By Announcement, Blog, OpenJS World, Project Update

LoopBack is the newest incubating project at the OpenJS Foundation

LoopBack is a popular Node.js framework for API creation and a platform to build large-scale Node.js applications using proven patterns with TypeScript and with support for SOAP and enterprise databases. Today, IBM announced it is contributing LoopBack to the OpenJS Foundation, trusting that the project will continue to grow and thrive with support from the community’s active core of developers. As it stands today, nearly half of all Loopback pull requests come from its community contributors outside of IBM.

“We are thrilled to welcome LoopBack into the OpenJS Foundation. As the vendor-neutral home to almost 40 open source projects, The OpenJS Foundation exists to sustain the JavaScript ecosystem on a global scale,” said Robin Ginn, OpenJS Foundation executive director. “We look forward to providing resources and support to LoopBack to help their community grow.”

“LoopBack joining as an incubating project is an important addition to the Foundation,” said IBM’s Joe Sepi, who is also the chairperson of the OpenJS Foundation Cross Project Council. “LoopBack is a great example of how interconnected JavaScript technologies can be and it’s always great to welcome new projects into the fold. On behalf of the OpenJS Foundation Cross Project Council, I am happy to welcome LoopBack to the foundation.”

LoopBack makes it easy to create a REST API with minimal coding. LoopBack provides a consistent way to design and implement APIs, including the REST layer, models, and ORM. These are all valuable benefits LoopBack presents as APIs enable businesses to expand the reach of their products and services to audiences of developers who consume those APIs.  Current users of LoopBack include GoDaddy, Symantec, IBM and others. 

Why Join OpenJS?

LoopBack was created in 2013 as the API economy and Node.js were taking flight. Since then, the open source project has reached a steady level of contributor diversity and product stability. Currently, LoopBack gets approximately 180K monthly downloads. Joining the OpenJS Foundation will help the open source project continue to grow in a vendor-neutral space with an open governance model. 

“We’re excited for the next chapter of LoopBack with the OpenJS Foundation as its new home,” said Raymond Feng, Co-founder and CTO at Abridged, Inc. “This is the thrilling moment that touches me professionally and personally as I have been developing, maintaining, and evangelizing the framework ever since I created LoopBack with Albert and Ritchie at StrongLoop in 2013.” Adds Feng, “ By betting Node.js as the great platform for API economy, we built LoopBack to help developers create APIs and Microservices in JavaScript/TypeScript that connect to databases, services, and infrastructure with minimal coding. I’m grateful that StrongLoop and IBM’s investment and sponsorship made it possible for LoopBack to continue to innovate and grow in past 8 years.”  Beyond the value of framework itself, LoopBack’s leadership has strived to build a diverse open source community and develop contributors and maintainers for the project. OpenJS Foundation is a natural next step for LoopBack as it truly reflects the project’s culture of collaboration and commitment to further grow the project and community under the open governance. 

Incubating projects under the OpenJS Foundation are projects that are in the process of completing their on-boarding checklist to join the foundation. There are currently more than 37 open source projects under the OpenJS Foundation umbrella.


The OpenJS Foundation provides a wide range of resources for organizations and individuals involved in the adoption and ongoing development of key JavaScript solutions and related technologies.

WebdriverIO: OpenJS Foundation Live Q &A

By AMA, Blog, Project Update, WebdriverIO

WebdriverIO was created to allow users to automate any application written with modern web frameworks, as well as native mobile applications for Android and iOS. WebdriverIO is a Project hosted at the OpenJS Foundation

Members of the WebdriverIO team recently joined the OpenJS Foundation for a live Q and A on YouTube. This aimed to give insight into how WebdriverIO works as well as where it expects to go in the future. This was moderated by Christian Bromann, and included insights from Kevin Lamping, Erwin Heitzman, and Wim Selles. Users were able to ask questions via Twitter and live YouTube chat. 

Questions ranged from how users can participate in the WebdriverIO project with no technical background to best practices for storing credentials and variables. 

The full AMA is available here: OpenJS Foundation AMA – Webdriver


0:00 Brief Introduction

0:59 Moderator Introduction

6:30 Donation Announcement

14:00 Why doesn’t support JEST?

17:40 Can I contribute with no background knowledge?

22:45 Could you mock responses through selenium grid?

24:14 for mobile apps?

25:50 Udemy/Coursera

29:58 best way to categorize test suite

30:55 How to achieve a good test environment?

34:08 Best practice for variables 

35:28 Where to store credentials

36:00 Testing Accessibility with WDIO

41:26 Could we ever see WebdriverIO use AI?

43:30 Sync Mode

48:38 Layer Automation

50:50 Who owns WDIO?

54:00 Where do you see Webdriver in 5 years?

To learn more about Webdriver and how you can get involved, please visit their website here

Node-RED Version 1.3 Available Now!

By Blog, Node-RED, Project Update

Node-RED, the flow-based programming tool, has released version 1.3 as of April 2021. Node-RED is a growth project at the OpenJS Foundation.

Node-RED is a low code method of programming event driven applications. Flow-based programming creates networks that lend themselves to visual representation, making it a more accessible way of programming. JavaScript functions can be built using a rich text editor, and a built-in library allows access to useful functions, templates or flows for re-use.

Visualization of browser-based, flow-based programming creating networks

Node-RED was originally created in 2013 by members of IBM’s Emerging Technology Services group and has been in open source development since. It is one of the founding projects of the JS Foundation in 2016 and came into the OpenJS Foundation through the 2019 merger with the Node.js Foundation. 

Users of Node-RED include Hitachi, Veritone, Go-IoT,, and many more.

Notable changes in Node-RED 1.3 include relabelling of tabs, nesting references in Change/Switch nodes, and a new plugin framework for Node-RED. To make it easier for developers to use extra npm modules, users can now set their function nodes to be automatically run and defined in their code. It is also now possible to configure a Change or Switch node to nest references to message properties. The new configuration of Change nodes is cleaner and easier to read. 

The new plugin framework for Node-RED allows for easier customization and feature addition. This feature is still in its infancy, but will serve as the backbone for new iterations. Extra functions are implemented via plugin as opposed to code, keeping the core code smaller and allowing for users to be more selective over what “extra” features they want. For now, there are two types of new plugins available. Editor theme plugins which make installing and enabling new themes easier, and library source plugins which allow for configuring of additional libraries within the editor. 

To learn more about the 1.3 release, you can read about it on the Node-RED website here

Project News: NativeScript v8.0

By Blog, NativeScript, Project Update

New version signals growth and evolution

This week, the NativeScript, an incubation project at the OpenJS Foundation, shipped version 8. NativeScript is an open source community driven framework which empowers JavaScript developers with access to native platform APIs directly. This release will include some major upgrades including streamlined development with a JavaScript-focused stack and improved efficiency with iOS and Android development, which is especially timely given feature parity is of utmost importance. Additionally, v8.0 will make cross-platform development effective, practical, and fun. Read the project’s blog here.

“NativeScript brings together the convenience of web development with the capabilities and performance of the native mobile world,” said NativeScript Technical Steering Committee member, Stanimira Vlaeva.

What’s new?

Users can expect the following updates in the latest release: 

* Official Apple M1 support

* webpack5 support

* First class a11y support

* CSS box-shadow support (requested since 2015!)

* CSS text-shadow support

* New `hidden` binding property for more performance dialing cases

* New official eslint rules for NativeScript projects

* New `RootLayout` container – offering more dynamic creative view development

* New @nativescript/debug-ios package for deep view level investigations on your simulator or device

* New @nativescript/apple-pay plugin

* New @nativescript/google-pay plugin

* New website and revamped docs to better represent the current and future of NativeScript

* The first official NativeScript Best Practices Guide

* and more streamlining of core to further prepare for continual evolutionary enhancements

NativeScript 8.0 will bring some valuable benefits including 

  • Reducing the costs with multiple platform deliveries and enhance long term maintenance of TypeScript based tech stacks
  • The ability for managers to engage with the large JavaScript resource workforce
  • The ability to integrate with any popular frontend framework that teams would like to use

This new release signals solid footing for growth and natural modern JavaScript evolutions by addressing some of the oldest requested features. These include adding structural integrity with official eslint package, adding support for creative view development via new RootLayout, affirming broad use case applicability via new Capacitor integration, support for latest webpack5 and a revamped website and documentation refresh,  to name a few.

Get Involved!

Come join the fun! Git clone and experiment with the source for any desire you may have. Get involved in public discussions surrounding NativeScript via the RFCs board: Join Discord channel to be in touch:

Project Update: nvm ships new version.

By Blog, nvm, Project Update

Today nvm released v0.38.0! This latest release includes new `nvm install` features, bug fixes, and updates to documentation.

Major updates include: 

  • Improvements to nvm install: OpenBSD source builds are now parallelized; nvm install -b will skip compiling from source
  • Bug fixes:
    •  nvm exec: ensure — stops argument parsing
    • fix variable issues on some shells; avoid conflicts with oh-my-zsh global variables
    • fix npm exec on older versions of npm 7
    • fix lts/-1 aliases being off-by-one
  • Lots of documentation improvements
  • Cloning the repo on windows should no longer fail due to test filenames

Check out the release notes:

Ajv Version 7, Big changes and improvements

By Announcement, Blog, Project Update

The following post was written by Evgeny Poberezkin, lead maintainer of Ajv (incubation project of the OpenJS Foundation). 

It’s been over a month since Ajv version 7 was released, and in this time many users have migrated to the new version. Ajv v7 is a complete rewrite that both changed the language to TypeScript and also changed the library design. I’m happy to share that it has been relatively smooth, without any major issues.

What’s new

I’ve written previously about what has changed in version 7, to summarize:

1. Support of the JSON Schema draft 2019-09 – users have been asking specifically for `unevaluatedProperties` keyword, which adds flexibility to the valuation scenarios, even if at a performance cost.

2. More secure code generation in case untrusted schemas are used. Execution of code that might be embedded in untrusted schemas is now prevented by design, on a compiler type system level (and you don’t need to use TypeScript to benefit from it, unless you are defining your own keywords).

3. Standalone validation code generation is now comprehensively supported, for all schemas.

4. Strict mode protecting users from common mistakes when writing JSON Schemas.

That is a big list of improvements that was possible thanks to Mozilla’s MOSS program grant.

Better for community

I’m also excited to share that Ajv v7  has grown contribution interest from its users, with some cases when independent users are interested to collaborate between them on some new features.

There are several reasons for that, I believe:

– the code is better organised and written on a higher level – it is easier to read and to change than before.

– documentation is now better structured with additional sections specifically for contributors – code components and code generation.

I am really looking forward to all the new ideas and features coming from Ajv users.

What’s changed and removed

These improvements came at a cost of a full library redesign, that requires being aware of these changes during migration:

– Importing from your code

– Installation

– Code generation performance

– Validation of JSON Schema formats

– Migrating from JSON Schema draft 4

Below these changes are covered in detail – they were causing migration difficulties to some users.

Importing Ajv from your code

To import Ajv in typescript you can still use default import:

 import Ajv from "ajv"
 const ajv = new Ajv()

But to import in JavaScript you now need to use `default` property of the exported object:

 const Ajv = require("ajv").default
 // or const {default: Ajv} = require("ajv")
 const ajv = new Ajv()

And if you use JavaScript modules you need to import Ajv this way:

 // from .mjs file
 import Ajv from "ajv"
 const ajv = new Ajv.default()

This is a compromise approach that leads to a bit simpler compiled JavaScript code size of Ajv, and, what is more important, allows to export additional things alongside Ajv and does not force dependencies to use `esModuleInterop` setting of TypeScript. Possibly, there is a better way to export Ajv – please share any ideas to this issue.

Ajv installation

Several users, in particular those who use `yarn` rather than `npm`, had issues related to version conflicts between old and new versions. Because Ajv is a dependency of many JavaScript tools, the users can have both version 6 and version 7 installed at the same time.

When version 6 was released 2 years ago there were a lot of version conflicts. Since then npm seems to have improved – it handles multiple versions correctly when performing a clean installation – at least I have not seen any example that shows version conflicts in this scenario. But when performing incremental installations version conflicts still happened to a few users.

This situation should resolve itself as dependencies migrate, and in all cases clean installation resolved the problem.

Code generation performance

Validation code that Ajv v7 generates is at least as efficient as code generated by v6, and in many cases it is faster – version 7 introduced several tree optimisations and other improvements for it. The primary objective to re-design code generation was to improve its security when using untrusted schemas and to make the code more maintainable.

As a side effect, it also led to the reduction of Ajv bundle size.

The downside that may be affecting some users though is that the code generation itself is 4-5 times slower.

For most users it won’t have an impact on the application performance, as schema compilation should only happen once, when the application is started, or when the schema is used for the first time. But there are several scenarios when it can be important:

1. When using schemas in short lived environments when validation is performed only once or few times per compilation – it may include serverless environments, short-lived web pages, etc. In this case you should explore the possibility of using the standalone validation code to compile all your schemas at build time. Ajv v7 improved the stability of generating standalone validation code and it is now supported for all schemas.

2. When a schema is generated dynamically for each validation (or to perform a small number of validations). There is no solution for such scenarios – Ajv (and any other validator that compiles schemas to code) is simply not a good fit for such scenarios, if the performance is critical. The main advantage of schema compilation is that the produced validation code is much faster than it would have been to interpret the schema. But if the schema is dynamic, then there is no benefit to the compilation – a validator that interprets the schema in the process of validation could be a better fit. While it may be 50-100 times slower to validate, it may still be faster than compiling schema to code. You need to run your own benchmarks and decide what is better for your application.

3. When you used Ajv incorrectly and compiled schema for each validation. The correct usage is either to use the same Ajv instance to manage both schemas and compiled validation functions, or to manage (cache) them in your application code. In Ajv v7 this incorrect usage is more likely to be noticeable both because of slower compilation speed and also because Ajv caches the functions using schema itself as a key and not it’s serialised presentation.

To summarize, if you use Ajv correctly, as it is intended, it will be both safer and faster, but if you use(d) it incorrectly it may become slower.

Caching compiled schemas

Ajv compiles schemas to validation code that is very fast, but the compilation itself is costly, so it is important to reuse compiled validation functions.

There are 2 possible approaches:

1. Compile schemas either at start time or on demand, lazily, and manage how validation functions are re-used in your application code:

 const schema = require("mu_schema.json")
 const validate = ajv.compile(schema)
 // ...
 // in this case schema compilation happens
 // when app is started, before any request is processed
 async function processRequest(req) {
   if (!validate(req.body)) throw Error("bad request")
   // ...

It is important that `ajv.compile` is used outside of any API endpoints, as otherwise ajv may recompile the schema every time it is used (depending whether you pass the same schema reference or not).

2. Add all schemas to Ajv instance, using it as a cache of compiled validation functions, later retrieve them using either the schema `$id` attribute from the schema or the key passed to `addSchema` method.

File `./my_schema.json`:

   "$id": "",
   "type": "object",
   "properties": {
     "foo": {
       "type": "string"


 const schema = require("./my_schema.json")
 ajv.addSchema(schema, "my_schema")
 // ...
 // schema compilation happens on demand
 // but only the first time the schema is used
 async function processRequest(req) {
   const validate = ajv.getSchema("")
   // or
   // const validate = ajv.getSchema("my_schema")
   if (!validate(req.body)) throw Error("bad request")
   // ...

If you are passing exactly the same (and not just deeply equal) schema object to ajv, ajv would use a cached validation function anyway, using schema object reference as a key.

But if you pass the new instance of the schema, even if the contents of the object is deeply equal, ajv would compile it again. In version 6 Ajv used a serialized schema as a cache key, and it partially protected from the incorrect usage of compiled validation functions, but it had both performance and memory costs. Some users had this problem ( when migrating to version 7.

Validation of JSON Schema formats

Format validation has always been a difficult area, as it is not possible to find an optimal balance between validation performance, correctness and security – these objectives are contradictory, and, depending on your application, you would need a different approach to validate the same format.

JSON Schema specification evolved to the point of declaring format validation as an optional, opt-in behaviour, and Ajv v7 made the same choice – formats are now released as a separate package ajv-formats.

Unlike JSON Schema specifies, Ajv does not just quietly ignore formats – it would have been error-prone – you have to explicitly configure it for the desired behaviour (or do not use formats in the schemas).

You have several options:

1. Fully disable format validation with the option `validateFormats: false`. In this case, even if you use formats in the schema, they will be ignored.

2. Define the list of formats that you want to be ignored by passing `true` values for some formats in `formats` option:

 new Ajv({formats: {email: true}})

The configuration above would allow and ignore `email` format in your schemas, but would still throw an exception if any other format is used. This approach is more performant than passing regular expressions `/.*/` or function `() => true` because they would have to be executed, and in case of `true` no validation code is generated when this format is used.

3. Use ajv-formats package – it includes all formats previously shipped as part of Ajv, some of the formats have two options – more performant and more correct (`fast` and `full` – see the docs to ajv-formats).

4. Define your own functions (or use some a 3rd party library) to validate formats that suit your application – you can pass functions to ajv for each format you use and you can even use asynchronous validation if, for example, you want to validate the existence and/or configuration of domain name as part of `email` or `hostname` validation.

The last approach to validate formats – defining your own functions or using a library – is strongly recommended as it allows you to achieve the right balance between validation security, speed and correctness that fits your application.

JSON Schema draft 4 should be used with version 6

Draft 4 of the JSON Schema is the first version that Ajv supported, and since then there were several important changes in the specification that made supporting multiple versions of JSON Schema in the same code unnecessarily complex.

JSON Schema draft 2019-09 has introduced further complexity, so the support for draft 4 was removed.

You can either continue using JSON Schema draft 4 with Ajv version 6, or if you want to have all the advantages of using Ajv version 7 you need to migrate your schemas – it is very simple with ajv-cli command line utility.

What is next

Thanks for continuing sponsorship from Mozilla, many new improvements are coming in Ajv – the new major version 8 will be released in a few months.

The most exciting new feature that was just released in version 7.1.0 is the support for the alternative specification for JSON validation – JSON Type Definition – it was approved as RFC8927 in November 2020. This is a much simpler and more restrictive standard than JSON Schema, and it enforces better data design for JSON APIs, prevents user mistakes and maps well to type systems of all major languages. See Choosing schema language section in Ajv readme for a detailed comparison.

Ajv version 8 will bring many additional features and stability improvements and also will support the changes in the most recent JSON Schema draft 2020-12.

The second exciting change that is coming soon is a new website for Ajv – to make the documentation more accessible and discoverable, and to make contributions easier.

Thanks a lot for supporting Ajv!