docs: Update obsolete default exports in package.json

[donysukardi]

Current example uses default, which is no longer valid based the following code

microbundle/src/index.js

Lines 262 to 265 in b1a6374

	function walk(exports) {
	if (typeof exports === 'string') return exports;
	return walk(exports['.'] || exports.import || exports.module);
	}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 1d720e9

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[rschristian]

That's absolutely a valid key, just not one we check (at the moment) while generating output. Nothing obsolete there.

In the past, when that was written, we never checked the children of "exports", just generated a file regardless of what you had listed. Have some ways to go before output customization is fully supported, but we're getting there.

This could change at some point though, see #853 (comment)

[donysukardi]

I see. I suppose it’s a regression then based on the linked issue. I copied the example in the readme and was surprised that it didn’t work

[rschristian]

There's no regression, that was never supported.

[donysukardi]

Then the example is incorrect given the current state

[rschristian]

It's correct, just not fulfilling the behavior you wish. You need to ensure yourself that the name matches up. Again, hopefully this will be better in the future, but for now, that might mean a post-build renaming/copying of files.

[sirianni]

I don't really understand the confusion here, clearly the example in the README is incorrect as @donysukardi points out.

[rschristian]

The confusion is that they believed export keys were no longer valid based on us not checking for them. We don't check for every key of exports to generate output for, and never have. It'd certainly be nice to be able to, but that's not the point we're at.

The example is valid and correctly formed, no issues with it.

I believe there's a PR open for adding default to the list of keys to check against.

Edit: Actually, that PR has been merged in and the patch released, everything should be working. @sirianni, do you have a specific problem with it?