Polymer Logo Home Guides Feature overview Try Polymer Install Polymer 3.x Tutorial: Build an element 1. Get set up 2. Add shadow DOM 3. Data binding & properties 4. React to input 5. Theming with custom properties About this release What's new in 3.0 Upgrade guide Release notes Custom elements Custom element concepts Define an element Declare properties Working with legacy elements Shadow DOM & styling Shadow DOM concepts DOM templating Style shadow DOM Custom CSS properties Events Handle and fire events Gesture events Data system Data system concepts Work with object and array data Observers and computed properties Data binding Helper elements Browser support Overview Polyfills ES6 and modules Tools Tools overview Polymer CLI CLI commands Create an element project Create an application project Document your elements Test your elements polymer.json specification Node support Build apps Overview App templates Build for production Serve your app The PRPL pattern Service worker Reference Glossary Global settings API Reference index polymer-element.js Elements array-selector.js custom-style.js dom-bind.js dom-if.js dom-module.js dom-repeat.js Mixins dir-mixin.js disable-upgrade-mixin.js element-mixin.js gesture-event-listeners.js mutable-data.js properties-changed.js properties-mixin.js property-accessors.js property-effects.js strict-binding-parser.js template-stamp.js Utils array-splice.js async.js case-map.js debounce.js flattened-nodes-observer.js flush.js gestures.js html-tag.js mixin.js path.js render-status.js resolve-url.js settings.js style-gather.js telemetry.js templatize.js Legacy class.js legacy-data-mixin.js legacy-element-mixin.js mutable-data-behavior.js polymer-fn.js polymer.dom.js templatizer-behavior.js

The Polymer library is in maintenance mode. For new development, we recommend Lit.

Contents

Polymer tools must support a wide range of developers, using a variety of operating systems, toolchains, and possibly corporate and IT support policies. To help our users plan ahead and understand what environments we support, this document details our guidelines and process for supporting versions of Node.js.

This support policy tries to balance the desire to support as many environments as possible with the cost of that support. The JavaScript and Node.js ecosystems have been moving at a very fast pace recently, delivering considerable speed and productivity benefits. We want to take advantage of these benefits to deliver better tools more quickly, but at the same time recognize it can be difficult or imprudent for users to keep up with this pace of change.

Luckily, Node has developed a clear release and long term support plan which we can base our support policy on. In developing this plan, we've made the assumption that our tools are run at development time, not in production, and developer environments are usually easier to update than production environments.

We support all "Current" and "Active LTS" releases of Node.js according to the Node.js Long Term Support Release Schedule, but not "Maintenance" releases.

This means we will support from two to three semver major versions of Node.js, depending on where we are in the Node LTS schedule. Currently we support 8.x and 10.x.

We support both the NPM and Yarn package managers.

Yarn should be drop-in compatible with npm, as it uses the same package.json format as npm and can install the same packages from the npm registry.

We support npm v3 and newer. If you don't have v3 or newer installed, you can upgrade npm by running npm i -g npm.

We support Windows 10, Linux and macOS (née OS X).

"Support" for an environment means we test in it, and will fix any issues specific to it. We ensure support for environments via continuous integration.

We run tests for our tools libraries on Travis CI, which covers Ubuntu Linux and Node.js v8. We also run the Polymer CLI tests, which cover most of the libraries, on Appveyor, which covers Windows 10.

We will be increasing coverage of libraries on Appveyor Windows environments and Travis macOS environments over time.

When we end support for an environment we will do so with a major version change so that legacy environments can depend on the old version. We will update CI configurations to stop testing on unsupported environments.

Unsupported environments will not necessarily stop working right away, but we will eventually use features that are only supported in newer environments.