We use the exports field in package.json to define the public interface of the package. This enforces boundaries between the intended public API and any internal structures/helpers that we use internally.
I had omitted most of the exports before, as they were mostly intended for SVGO itself to consume. However, consumers of the library are using these functions while maintaining their custom plugins, so we're changing how they're exported, but the functions will otherwise still be available in v4.
- import { querySelector, querySelectorAll } from 'svgo/lib/xast.js';
+ import { querySelector, querySelectorAll } from 'svgo';
- import _collections from 'svgo/plugins/_collections';
+ import _collections from 'svgo';
- import type { XastElement, XastRoot, XastChild } from 'svgo/lib/types';
+ import type { XastElement, XastRoot, XastChild } from 'svgo';
You get the idea, similar to other libraries like React, we're pretty much exporting everything from our top-level namespace, i.e. svgo and svgo/browser.
For SVGO v4, we're changed how we handle exports.
I had omitted most of the exports before, as they were mostly intended for SVGO itself to consume. However, consumers of the library are using these functions while maintaining their custom plugins, so we're changing how they're exported, but the functions will otherwise still be available in v4.
You get the idea, similar to other libraries like React, we're pretty much exporting everything from our top-level namespace, i.e.
svgoandsvgo/browser.