Modern Web development one jump at the time
Photo by Denny Luan on Unsplash
The ungap project was born after years of attempts to always fix the same issue, but never in a modular way and, most importantly, never in a single, 100% code covered, organization.
Each module is written in ES5 compatible syntax to avoid both unnecessary transpilers bloat and potentially unexpected behaviors. Each module is also 100% code-covered through tests able to verify the whole API both as native and polyfilled version. The constrains per module are the following:
 as example: stripped out features detections
There are parts of the specifications that are very hard, if not impossible, to polyfill. The main purpose of this project is to help developers move forward, and possibly without unnecessary bloat. This basically means that polyfills are written to support 99% of the use cases, without granting 100% spec compliance.
If you need that, which again is basically impossible in most of the cases, feel free to keep using whatever monolithic polyfill or approach you were using before.
Every single module is made available as ESM, through the
module field, CJS via
main field, and browser script polyfill / patch via
unpkg field so that you can use directly the unpkg CDN.
// as ECMAScript module import WeakSet from '@ungap/weakset'; // as CommonJS module const WeakSet = require('@ungap/weakset'); // as Browser global patch <script src="https://unpkg.com/@ungap/weakset"></script>
Essentials modules covers most common use cases without going full bloated API.
As example, the essential-map exposes only
has which is most of the time everything one needs, as opposite of going full map.
The main benefit of the essential modules is their size, simplicity, or even performance.
\u2028|9in all JS engines with a
Element.containscompatible with all JS engines with a DOM env.
Reflect.ownKeyscompatible with all JS engines.
FinalizationGroupcompatible with any engine that already has a
Ungap utilities are meant to simplify cross browser development without the bloat of a whole polyfill.
new CustomElement()due WebKit/Safari built-in extends caveat.
If you are targeting modern browsers only, you might want to exclude some unnecessary code from various ungapped APIs.
Following a list of plugins which aim is to address those cases:
Each module is under the npm default ISC license.
You are welcome to join the organization after your first module is published.
In order to do so, please take any already available module as example of how to create and test any code you need.
The main guideline though, can be summarized as such:
I have personally no interest in enforcing any specific linting rule or code style, as long as common sense and good practices are part of the code.
If these basic constrains are good enough for you, please do help this project grow, allowing the community to leave all monolithic polyfills part of the past.
If you have further questions, you can DM me @webreflection 
 my DMs are open