Skip to main content

2.0 migration

Shifted Node.js/npm versions and dropped v10 support

Since Node.js v12 has reached end of life, Packemon now requires at minimum v14.15 and above to run. Furthermore, we're entirely dropping v10 support, and shifting v12 into legacy, v14 into stable, v16 into current, and the new v18 into experimental. As part of this process, we are also bumping minimum requirements and coupled npm versions.

The updated support compatibility table is as follows.

Before

LegacyStableCurrentExperimental
Node>= 10.3.0>= 12.17.0>= 14.16.0>= 16.0.0
npm>= 6.1.0>= 6.3.0>= 6.14.0>= 7.0.0

After

LegacyStableCurrentExperimental
Node>= 12.22.0>= 14.15.0>= 16.12.0>= 18.0.0
npm>= 6.14.0>= 6.14.0>= 8.1.0>= 8.5.0

Notable changes:

Shifted browser targets and dropped IE and iOS < 12 support

With Node.js versions changing (above), it was due time to audit the browser targets as well, and as such, we have dropped Internet Explorer support entirely. This only affected legacy support.

We also dropped iOS 8-11 support, as these versions are more than 5 years old. The minimum supported version is now iOS 12, which was released in 2018.

The updated support compatibility table is as follows.

Before

LegacyStableCurrentExperimental
Browser>= IE 11defaults, not IE 11> 1%, not deadlast 2 chrome versions
Native>= iOS 8>= iOS 10>= iOS 12>= iOS 14

After

LegacyStableCurrentExperimental
Browser>= 0.10%, not IE 11defaults, not IE 11>= 1%, not deadlast 2 chrome versions
Native>= iOS 12>= iOS 13>= iOS 14>= iOS 15

A major notable change is that all targets are now on ES2015, which means you should see const usage, arrow functions, and more (we no longer downlevel). If this causes issues, you should ask yourself why you still need 7 year old syntax.

Removed multiple format support when configuring a package

Previously it was possible to pass a list of formats to the format setting, and Packemon will build them all (according to the platform). For example, a Node.js library could have built cjs and mjs versions. However, in an effort to reduce the dual package hazard problem, Packemon now only supports a single format.

// Before
{
"format": ["cjs", "mjs"]
}
// After
{
"format": "mjs"
}

With that being said, you can work around this restriction by passing an array of configuration objects to the packemon setting. We do not guarantee this will work correctly.

When choosing the esm format, Packemon will automatically build a lib format. This is an exception for backwards compatibility until the Node.js ecosystem is fully on modules.

Removed api support from --declaration

We removed support for the api option, which uses @microsoft/api-extractor to generate a single .d.ts file. This feature was rarely used, overcomplicated the implementation, and had weird edge cases that we couldn't solve on our end.

Because of this change, the --declaration option on the command line is now a flag with no value.

# Before
--declaration standard
--declaration api

# After
--declaration

Removed the --analyze option

Since Packemon now supports customizing the Rollup config, the rollup-plugin-visualizer plugin can now be implemented in user-land, and doesn't need to exist in core.

const path = require('path');
const visualizer = require('rollup-plugin-visualizer');

module.exports = {
rollupInput(config) {
config.plugins.push(
visualizer((outputOptions) => ({
filename: path.join(outputOptions.dir, 'stats.html'),
gzipSize: true,
open: true,
sourcemap: true,
template: 'treemap',
})),
);
},
};

Removed .babelrc support within each package

Packemon historically supported .babelrc files within packages as a means to allow custom Babel plugins and presets per package. However, this wasn't really documented, and since we now support Packemon config files, we suggest using that instead.

packages/foo/.babelrc
// Before
{
"plugins": ["babel-plugin-formatjs"]
}
packages/foo/.packemon.js
// After
module.exports = {
babelOutput(config) {
config.plugins.push('babel-plugin-formatjs');
},
};

Output of formats esm and mjs are now considered a module

While this change isn't technically breaking, and more of an accuracy fix towards the specification, all files generated through the esm and mjs formats are now considered modules (using generatedCode.symbols). This is in addition to the __esModule property that is already being defined.

What this means, is that any imported value within a module context that is stringified will now return "Module". This can mainly be used for feature detection.