Congrats to the ESLint team on their most recent release, v7.0.0! This new release brings new updates including improved developer experience, core rule changes, new ESLint class, and much more.
ESLint v7.0.0 Highlights:
Dropping support for Node.js v8
Node.js 8 reached EOL in December 2019, and we are officially dropping support for it in this release.
Core rule changes
The ten Node.js/CommonJS rules in core have been deprecated and moved to the eslint-plugin-node plugin.
Several rules have been updated to recognize bigint literals and warn on more cases by default.
eslint:recommended has been updated with a few new rules: no-dupe-else-if, no-import-assign, and no-setter-return.
Improved developer experience
The default ignore patterns have been updated. ESLint will no longer ignore .eslintrc.js and bower_components/* by default. Additionally, it will now ignore nested node_modules directories by default.
ESLint will now lint files with extensions other than .js if they are explicitly defined in overrides.files – no need to use the --ext flag!
ESLint now supports descriptions in directive comments, so things like disable comments can now be clearly documented!
Additional validation has been added to the RuleTester class to improve testing custom rules in plugins.
ESLint will now resolve plugins relative to the entry configuration file. This means that shared configuration files that are located outside the project can now be colocated with the plugins they require.
Starting in ESLint v7, configuration files and ignore files passed to ESLint using the –config path/to/a-config and –ignore-path path/to/a-ignore CLI flags, respectively, will resolve from the current working directory rather than the file location. This allows for users to utilize shared plugins without having to install them directly in their project.
New ESLint class
The CLIEngine class provides a synchronous API that is blocking the implementation of features such as parallel linting, supporting ES modules in shareable configs/parsers/plugins/formatters, and adding the ability to visually display the progress of linting runs. The new ESLint class provides an asynchronous API that ESLint core will now using going forward. CLIEngine will remain in core for the foreseeable future but may be removed in a future major version.
This blog was written by Michael Dawson and Bethany Griggs, with additional contributions from the Node.js Community Committee and the Node.js Technical Steering Committee. This post initially appeared on the Node.js Blog. Node.js is an Impact Project of the OpenJS Foundation.
We’re excited to announce that Node.js 14 was released today! The highlights in this release include improved diagnostics, an upgrade of V8, an experimental Async Local Storage API, hardening of the streams APIs, removal of the Experimental Modules warning, and the removal of some long deprecated APIs.
Node.js 14 replaces Node.js 13 as our current release line. As per the release schedule (https://github.com/nodejs/Release#release-schedule), Node.js 14 will be the `Current` release for the next 6 months, and then promoted to Long-term Support (LTS) in October 2020. As always, corporate users should wait to upgrade their production deployments until October when Node.js is promoted to LTS. However, now is the best time to start testing applications with Node.js 14, and try out new features.
As a reminder — both Node.js 12 and Node.js 10 will remain in long-term support until April 2022 and April 2021 respectively (more details on the LTS strategy here).
Before we dive into the features highlighted for this release, it’s important to note that new features added to the master flow quickly into the current release. This means that significant features become available in minor releases without too much fanfare. We’d like to take this opportunity to highlight some of those in the Node.js 14 release even though they may already have been backported to earlier releases.
Diagnostic Report goes Stable
The diagnostic report will be released as a stable feature in Node.js 14 (it was added as an experimental feature in Node.js 12). This is an important step in the ongoing work within the project to improve and build up the diagnostics available when using Node.js and the ease with which they can be used, with much of this work is pushed forward by the Node.js Diagnostics Working Group.
The diagnostic report feature allows you to generate a report on demand or when certain events occur. This report contains information that can be useful to help diagnose problems in production including crashes, slow performance, memory leaks, high CPU usage, unexpected errors and more. For more information about the diagnostic report feature, see https://medium.com/the-node-js-collection/easily-identify-problems-in-node-js-applications-with-diagnostic-report-dc82370d8029. As a stable feature there will be one less command-line option needed to enable Diagnostic reports and it should be easier for users to enable it in production environments.
V8 upgraded to V8 8.1
Enables calendar and numberingSystem options for Intl.DateTimeFormat — MDN
For more information about the new features in V8 checkout the Node.js V8 blog: https://v8.dev/blog.
Experimental Async Local Storage API
The project has been working on APIs to help manage context across Asynchronous Calls over a number of releases. The experimental Async Hooks API was introduced in earlier versions as part of this work. One of the key use cases for Async Hooks was Async Local Storage (also referred to as Continuation Local Storage). There have been a number of npm modules that have provided APIs to address this need, however, over the years these have been tricky to maintain outside of Node.js core and the project reached a consensus that exploring having Node.js provide an API would make sense. The 14.x release brings an experimental Async Local storage API (which was also backported into 13.10) https://nodejs.org/api/async_hooks.html#async_hooks_class_asynclocalstorage. We are looking for the community to try out this API and give us feedback on abstraction model, API interface, use case coverage, functional stability, naming, documentation etc. so that we can work on getting it out of experimental in later releases. The best way to provide feedback is to open an issue in the diagnostics repository here (https://github.com/nodejs/diagnostics/issues) with a title along the lines of “Experience report with AsyncLocalStorage API”.
This release includes a number of changes marked as SemVer major in the Node.js Streams implementation. These changes are intended to improve consistency across the Streams APIs to remove ambiguity and streamline behaviors across the various parts of Node.js core. As an example, http.OutgoingMessage is similar to stream.Writable and net.Socket behaves exactly like stream.Duplex. A notable change is that the `autoDestroy` option is now defaulted to true, making the stream always call `_destroy` after ending. While we don’t believe these SemVer major changes will affect most applications, as they only change edge cases, if you rely heavily on Streams it would be good to test while Node.js 14 is the current release so that it is ready for when Node.js 14 becomes LTS in October 2020.
Experimental Web Assembly System Interface
Packages written in Web Assembly for Node.js bring the opportunity for better performance and cross-platform support for certain use cases. The 14.x release includes an experimental implementation of the Web Assembly System Interface (WASI) in order to help support these use cases. While not new to Node.js v 14, this is noteworthy as WASI has the potential to significantly simplify the native modules experience. You can read more about it in the API docs: https://nodejs.org/api/wasi.html.
Removal of Experimental Modules Warning
In Node.js 13 we removed the need to include the ` — experimental-modules` flag, but when running EcmaScript Modules in Node.js, this would still result in a warning `ExperimentalWarning: The ESM module loader is experimental.`
As of Node.js 14 there is no longer this warning when using ESM in Node.js. However, the ESM implementation in Node.js remains experimental. As per our stability index: “The feature is not subject to Semantic Versioning rules. Non-backward compatible changes or removal may occur in any future release.” Users should be cautious when using the feature in production environments.
The ESM implementation in Node.js is still experimental but we do believe that we are getting very close to being able to call ESM in Node.js “stable”. Removing the warning is a huge step in that direction.
New compiler and platform minimums
Node.js provides pre-built binaries for a number of different platforms. For each major release, the minimum toolchains are assessed and raised where appropriate.
This release coincides with us moving all of our macOS binaries to be compiled on macOS 10.15 (Catalina) with Xcode 11 to support package notarization. As binaries are still being compiled to support the respective compile targets for the release lines, we do not anticipate this having a negative impact on Node.js users on older versions of macOS. For Node.js 14, we’ve bumped the minimum macOS target version to macOS 10.13 (High Sierra).
On our Linux based platforms, for Node.js 14 the minimum GCC level remains at GCC 6, however, we plan to build/release the binaries for some of the platforms with GCC 8.
Node.js 14 will also not run on End-of-Life Windows distributions.
Further details are available in the Node.js BUILDING.md.
Call to action
For the 6 months, while it is in the ‘current’ phase, Node.js 14 will receive the most new features that are contributed to Node.js. For the next 6 months, this release line is perfect for trying out the latest features, testing the compatibility of your project with the latest Node.js updates and giving us feedback so that the release is ready to transition to LTS in October.
We’d like to use this opportunity to say a big thank you to all the contributors and Node.js collaborators that made this release come together. We’d also like to thank the Node.js Build Working Group for ensuring we have the infrastructure to create and test releases and making the necessary upgrades to our toolchains for Node.js 14.
The OpenJS Foundation recently hosted its monthly Ask Me Anything with folks from the webhint team. webhint, a hosted project at the Foundation, is a customizable linting tool that helps you improve your site’s accessibility, speed, cross-browser compatibility, and more by checking your code for best practices and common errors. Pretty useful stuff, huh!?
This month’s AMA featured maintainers from the jQuery project. Jory Burson, OpenJS Foundation Community Manager, moderated the discussion with Dave Methvin and Timmy Willison. Dave Methvin has been a contributor to the jQuery project since 2006, and led many project initiatives during his 14-year history with the project, notably leading releases for core versions 1.7-2.1. Timmy Willison has been a jQuery Core Team member since 2011, and its Core Team Lead since 2015. Timmy is also the Lead Front-End Engineer at Spokestack.
If you are interested in supporting or becoming involved, there are a few ways to do so! 1. Check out the project’s GitHub repo and look for “help wanted tags” 2. Keep your versions of jQuery, especially if you are on 1 or 2. There are tools like jQuery migrate to help. If you are using migrate, take it out for production.
For more insights, check out the full replay below.
The next AMA features the webhint team and is happening March 4, 2020 at 9 am PT. To submit your questions, go to this form.
Congrats to the Electron team on their latest version release, Electron 8.0!
This new release includes upgrades to Chromium 80, V8 8.0, and Node.js 12.13.0. Read about all the details on the Electron blog here. Learn more about Electron and why it has joined the Foundation as an incubation project.
“We’re heading into 2020 excited and honored by the trust the Electron project leaders have shown through this significant contribution to the new OpenJS Foundation,” said Robin Ginn, Executive Director of the OpenJS Foundation. “Electron is a powerful development tool used by some of the most well-known companies and applications. On behalf of the community, I look forward to working with Electron and seeing the amazing contributions they will make.”
Electron’s cross-platform capabilities make it possible to build and run apps on Windows, Mac, and Linux computers. Initially developed by GitHub in 2013, today the framework is maintained by a number of developers and organizations. Electron is suited for anyone who wants to ship visually consistent, cross-platform applications, fast and efficiently.
“We’re committed to open source and developer collaboration, and thrilled for Electron to be a part of the Foundation’s incubation program,” said Sarah Novotny, Partner PM Manager, Azure, Microsoft. “We look forward to further enhancing the open source project for contributors, maintainers, and developers building on the framework; while exposing the project to a broader audience.”
“The Cross Project Council is thrilled to bring Electron into the OpenJS Foundation community,” said Joe Sepi, Cross Project Council Chair, and Open Source Engineer & Advocate at IBM. “Collectively, we are building something sustainable for the long-term benefit of community members and end-users. We are excited to work with Electron, and to have them be part of our mission.”
“On behalf of the OpenJS Foundation Board of Directors, it’s my pleasure to welcome Electron as the newest incubating project to the Foundation,” said Todd Moore, OpenJS Foundation Board Chair and Vice President of Open Technology and Developer Advocacy at IBM. “Bringing Electron into the Foundation is a great way to cap 2019, and continue to build our momentum into next year.”
Representatives from Electron will be featured in both a keynote and breakout session at Node+JS Interactive.
About OpenJS Foundation
Fastify is an open source web framework for Node.js focused on providing one of the best developer experiences with the least overhead and a powerful plugin architecture. They are joining the OpenJS Foundation’s incubation program.
Fastify, inspired by Hapi and Express, is built for speed while offering a solid developer experience. It powers large organizations and products, including CAR2GO, Gumlet, Knock, UNIQ, Unhandled, and Vectra. Fastify is partially sponsored by NearForm.
Fastify already has 12.5K GitHub stars and 804 GitHub forks. This kind of growth brings more business and legal issues along with it. By joining OpenJS Foundation, Fastify is looking to create a neutral community structure ready to scale.
Highly performant: Can serve up to 80 thousand requests per second, as the framework adds no overhead to Node.js core.
Extendible: Fully extensible via lifecycle hooks, plugins and decorators
Schema based: Recommend using JSON Schema to validate routes and serialize outputs
Developer friendly: Built to be expressive and to “help the developer in their daily use, without sacrificing performance and security”
“We’ve been working on Fastify now for 3 years. It was born out of a desire for a HTTP framework with extremely low overhead and astonishing speed,” said Matteo Collina, Project Champion. “We are delighted to see it powering many organizations today – in commercial use and in support of humanitarian causes such as the HospitalRun application where Fastify is enabling a unique modular solution thanks to its plug-in system, developer satisfaction, and framework speed. By joining OpenJS Foundation’s incubation program, Fastify will no doubt open significant new and unimagined opportunities for the future.”
For those curious about contributing to Fastify, their core philosophy is to promote contributions from the community, rather than just have a core team pushing forward a specific agenda.
Why not start now? The Fastify GitHub repo README file provides installation instructions using npm or yarn, and shows how to use Fastify CLI to create new projects, manage plugins, and perform a variety of development tasks testing and running the application. Full details here: www.fastify.io
AMP enters the open source foundation to broaden open governance, drive diverse, cross-industry adoption and continue improving the web for all.
“AMP is a great example of a community and technology focused on improving web performance and experience for all,” said Robin Ginn, Executive Director of the OpenJS Foundation, “On behalf of the Foundation, I am happy to welcome AMP and I look forward to seeing their progress to support a faster, open web.”
Now in its fourth year, AMP, a multi-stakeholder open source project initially backed by Google and used across a broad range of organizations, allows any publisher to have pages load quickly on mobile devices. Used in billions of pages on more than 30 million domains, AMP integrates with countless products and companies, including Google and Microsoft who each implement their own AMP Cache.
As a continuation of its adoption of an open governance model in late 2018, AMP’s cross-industry Technical Steering Committee agreed that the next step would be to submit an application for the project to join the OpenJS Foundation. This decision was further supported by its Advisory Committee representing constituencies from publishers, CDNs, browser vendors, open web advocates, and e-commerce and platform companies.
After completing the incubation process and officially joining the OpenJS Foundation, AMP will enable a wider variety of contributions from a wider audience, both technical and strategic. Additionally, a move to the OpenJS Foundation aims to develop and showcase the entirety of AMP’s benefits and capabilities, outside of the advantages to publishers.
“Now in our fourth year, AMP is excited for the next step on our journey,” said Malte Ubl, Member of the AMP Project Technical Steering Committee. “We’ve been considering the best home for AMP for some time. We decided on the OpenJS Foundation because we feel it’s the best place for us to help us to cater to our diverse group of constituencies. This step builds on previous moves we’ve made toward open governance and helps us focus on transparency and openness.”
“As a Platinum member of the OpenJS Foundation and huge proponent for thriving open-source communities, we are thrilled to see AMP take this step with the Foundation,” said Myles Borins, Developer Advocate for Google and OpenJS Foundation Board Vice Chairperson.“The opportunity to improve the web is vast, and AMP has a role to play in that. We see no better place for AMP to accomplish these goals than with the OpenJS Foundation.”
“As an AMP contributor and framework user having integrated AMP into different products including owning our own AMP Cache, we fully support and encourage this move,” said Saulo Santos, Engineering Manager, Bing Experiences, Microsoft. “AMP is helping to improve the web, and entering it into the Foundation will only be a continuation of these efforts.”
About OpenJS Foundation
Frequently Asked Questions
Why is AMP joining the OpenJS Foundation?
AMP has been taking very thoughtful steps to ensure its long-term commitment to its vision (A strong, user-first open web forever) and mission (Provide a user-first format for web content, supporting the long-term success of every web publisher, merchant, and advertiser).
In 2018, after community concerns around its ties to Google as well as concerns around scaling the project, AMP adopted an open governance model that is mirrored after the Node.js Foundation and JS Foundation. They adopted this model to scale as well as to give a voice to all constituents of the community, including those who cannot contribute code themselves, such as end-users.
How will joining the Foundation solve some of the past issues pertaining to governance AMP has faced and currently faces?
The OpenJS Foundation prides itself on vendor neutrality. Our vested interest resides solely in the ecosystem and the projects that contribute to that ecosystem. The OpenJS Foundation’s Cross Project Council is committed to supporting AMP in addressing these issues and ensure continued progress. During onboarding, AMP will also go through a multi-step process including adopting the OpenJS Foundation Code of Conduct, transferring domains and trademarks and more to graduation from incubation. AMP has made incredible strides by adopting a new governance model and by joining the OpenJS Foundation, they’ve made their intentions clear-AMP is committed to its vision of “A strong, user-first open web forever.”
Currently, the AMP runtime is hosted on the same infrastructure as the Google AMP Cache. Doesn’t this present serious issues?
The end goal is to separate the AMP runtime from the Google AMP Cache. The Project is currently in the incubating stage and Project leaders are still determining the next steps. Ideally, hosting and deployment of the AMP runtime to the CDN would fall under the purview of the OpenJS Foundation, much like the foundation is handling other projects CDNs, such as the jQuery CDN.
Untangling the runtime from the cache is a complex endeavor requiring significant investments of time and effort which would be planned and implemented in collaboration with the foundation and industry stakeholders during and after incubation.
The OpenJS Foundation CPC is committed to having a long-term strategy in place to address this issue by the end of AMP’s incubation.
How will AMP joining the Foundation address the lack of contributor diversity/inclusion? Currently, only past or current Google employees have commit rights.
AMP has taken key steps to guide how decisions are made in a more open and transparent way. The first step was to adopt a new governance model represented by multiple stakeholders. By joining the Foundation, which is a vendor neutral organization, AMP will be able to continue down this path. One of the reasons AMP is joining the Foundation is so they can have more of an inclusive contributor base. The Cross Project Council and AMP will be working on this together.