Type declarations broken in NPM packages

[brandonpayton]

It appears that NPM packages published after #1593 have type declarations that use relative paths rather than the actual NPM package names. Editors are unable to utilize the type declarations because their imports and exports cannot be satisfied.

The *.d.ts files use paths to external packages like this:

import { PHP, UniversalPHP } from '../../../php-wasm/universal/src/index.ts';

When what we want is for them to use paths like this:

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

Thanks to @psrpinto for reporting.

[brandonpayton]

Yesterday, I spent some time digging through our build setup and looking at TypeScript compiler options and haven't yet found a good fix beyond just post-processing the built type declarations.

Perhaps there might be some way, if our source directories were named like the published package names and our TypeScript configs were adjusted. It's not clear to me.

But we have the package alias mapping and the original source paths, so it should be fairly straightforward to fix the paths ourselves.

[brandonpayton]

I started playing with ts-morph tonight, and it looks pretty straightforward. Hopefully, we can finish writing a fixer for the type declarations in the morning. It might be a good thing to add to our package-json nx executor.

[brandonpayton]

@adamziel said there may be a simpler fix for this, so I'll put this on hold so he has time to check on that.

[psrpinto]

(There's a test repo that shows the issue at: https://github.com/psrpinto/playground-ts-test)

While some of the typescript issues have indeed been fixed (e.g. StartPlaygroundOptions now has correct types), the PlaygroundClient type still doesn't work, sadly.

I think this might be because PlaygroundClient is defined as:

export type { PlaygroundClient, MountDescriptor } from '@wp-playground/remote';

but @wp-playground/remote is not a package at npmjs.com

[psrpinto]

(I took the liberty of reopening the issue, I hope that's ok)

[bgrgicak]

(I took the liberty of reopening the issue, I hope that's ok)

Thanks for doing that @psrpinto!

You are correct the issue is still there and it's because the @wp-playground/remote package isn't public.

After talking with @adamziel, we concluded that the best way forward would be to publish @wp-playground/remote as a package of types and leave the other code unpublished. This package contains all the WordPress and WASM files and can be 600MB+, and we don't want people to download such a huge package only to get access to types.

[bgrgicak]

@psrpinto and I took a look at this today and figured out you can build a type file using dts-bundle-generator.

packages/playground/remote/project.json

"build:rollup-declarations": {
			"executor": "nx:run-commands",
			"options": {
				"commands": [
					"npx dts-bundle-generator -o packages/playground/remote/src/rollup.d.ts -- packages/playground/remote/src/index.ts",
					"rimraf dist/packages/playground/remote/rollup.d.ts",
					"cp packages/playground/remote/src/rollup.d.ts dist/packages/playground/remote/rollup.d.ts"
				],
				"parallel": false
			}
		},

This allows us to run npx nx run playground-remote:build:rollup-declarations and generate a type file that works for @psrpinto.

@adamziel we got stuck at deciding what to do with the typefile. We could publish it as the @wp-playground/remote package, or we could publish it under a different name like @wp-playground/remote-types.

An alternative would be to add the types to the @wp-playground/client package, but that would mean the Client build-depends on the Remote build.

[psrpinto]

I just noticed that the build process for remote already generates the types, under dist/, so another option could be to have the build process of client/ copy the relevant files (e.g. dist/packages/playground/remote/playground-client.d.ts) into dist/packages/playground/client.

This would mean that the client's build would depend on the remote's build, not sure that's acceptable.

[adamziel]

Let's just publish only the .d.ts types as the @wp-playground/remote package and include a README explaining this is just for types. Otherwise we'd need to rewrite the import from "@wp-playground/remote"; statements as import from "@wp-playground/remote-types"; or so, copy the files, use more scripts, make sure it keeps working as we add more packages and interdependencies. It sounds complex. Let's stick to simplicity.

[bgrgicak]

@psrpinto I reassigned this one to you, let me know if you need help.

[bgrgicak]

After releasing the @wp-playground/remote package I've noticed it doesn't contain any type files. I'm reopening the issue for us to investigate the missing type files.

@psrpinto would you maybe have time to take another look at this?

[psrpinto]

Oops, thanks for bringing this to my attention, I'm on it.

[psrpinto]

I can confirm that the type definitions now work correctly, since v1.0.8.