chore: use type PackageJson from type-fest

[shulaoda]

Summary

The preparatory work for PR #88 is to avoid endless resolution of branch conflicts.

Checklist

• Tests updated (or not required).
• Documentation updated (or not required).

[shulaoda]

@Timeless0911 cc

[Timeless0911]

I think there is no need to import this dependency. Is there any use?

[shulaoda]

I think there is no need to import this dependency. Is there any use?

It mainly utilizes the type PackageJson, which we will use in PR #88. Perhaps we should simply detach it and embed it inside?

[Timeless0911]

Introducing additional packages will cause that if we provide a public js API in the future, its type will not be bundled since we use bundleless DTS. We need to avoid relying on this type in our public API, this creates an extra mental burden.

[fi3ework]

We want Rslib's dependencies to be as minimal as possible, and type-fest is only used for type imports here, so we don't want it to be included in dep.

Ideally, we should be able to specify type-fest as a devDep without mental burden, and then bundle in the bundled dts. However, currently, there's no battle-tested dts bundle method available, so Rslib still uses bundleless types for now, and we might switch to bundle in the future.

Copying the usable code (like https://github.com/sindresorhus/type-fest/blob/main/source/package-json.d.ts#L221-L225) seems to be the best solution for now.

[shulaoda]

Is it okay to do this?

[fi3ework]

Overall it looks good, because we have copied the d.ts code, so we can do some further optimization here

1. Remove unnecessary fields and keep only the fields that may be needed now and in the future to reduce the size of d.ts (exports / main / module / types / publishConfig, there may be others that I haven't thought of yet, we can continue to copy from type-fest later).
2. Remove the legacy writing method of declare namespace and adopt the ESM writing method.

[shulaoda]

Remove unnecessary fields and keep only the fields that may be needed now and in the future to reduce the size of d.ts.

I will complete the rest in PR #88