✨ Alias default exports with named exports

[wwilsman]

What is this?

Default exports are a handy convenience for ES modules. However, with dynamic imports and commonjs modules, the default export must always be destructured due to default being a reserved word.

// esm
import thing from './thing';
// commonjs
const { default: thing } = require('./thing');
// dynamic import
const { default: thing } = await import('./thing');
// re-export
export { default as thing } from './thing';

By exporting defaults as named exports and aliasing them to default exports, much cleaner code can be written:

// esm
import thing from './thing';
// commonjs
const { thing } = require('./thing');
// dynamic import
const { thing } = await import ('./thing');
// re-export
export { thing } from './thing';

Tangential changes

• While adding a named @percy/env export, I felt compelled to rename the class to match the package name more accurately (PercyEnv).

• Packages that rely on @percy/core frequently need to perform some sort of request and utilize request from @percy/client to do so. When we add support for Yarn 2+, these packages will need to specifically declare a direct dependency on @percy/client, which will then trigger extra unnecessary dependency notifications.

  This small inconvenience can be alleviated by re-exporting request through @percy/core which already has a direct dependency on @percy/client. While this PR adds the necessary export, imports throughout other packages will need to be updated when adding support for Yarn 2+.

[Robdel12]

🏁

[Robdel12]

💥