Use the correct imports in the generated .d.ts files

[adamziel]

When using @wp-playground/client with TypeScript, the IDE doesn't seem
to be able to recognize types. This is because the published types
contain fragments such as:

import { Emscripten, MountHandler, PHP } from '../../../universal';

Which are relative to the build directory on the building machine.

This PR sets the pathsToAliases option of the vite-dts-plugin to
false to retain the packages names in those declaration files.

import { Emscripten, MountHandler, PHP } from '@php-wasm/universal';

Testing instruction

Run npm run build and grep the dist directory for ../../. There
should be no matches:

grep '\.\./\.\./' -R ./ | grep '\.d\.ts' | grep import

Inspect a few files, such as dist/packages/php-wasm/web/lib/get-php-loader-module.d.ts, and confirm they import from the proper package names.

Closes #1725

cc @brandonpayton

[brandonpayton]

It looks like this works well. Thank you!

Intuitively, I would have thought the config update would be pathsToAliases: true instead of pathsToAliases: false because, in development, @wp-playground/client maps to a relative path. In that arrangement, isn't @wp-playground/client the alias, and wouldn't that mean we'd want the build to ensure the type declarations import/export using those aliases?

Regardless of whether my understanding is conceptually correct on the TS side, it looks like pathsToAliases: false leads to the desired outcome with vite-dts-plugin.

[brandonpayton]

I also inspected export ... from paths, and everything looks good!

[adamziel]

Intuitively, I would have thought the config update would be pathsToAliases: true instead of pathsToAliases: false

I thought the same thing! I tried with true first, but nothing happened and I saw that was the default value so I tried false without much expectations and it worked!

[brandonpayton]

I saw that was the default value so I tried false without much expectations and it worked!

I'm so glad you tried it! Thanks again :)