[Feature] Allow typings to be set using publishConfig about berry HOT 7 CLOSED

Set the main to the typescript file instead of the built javascript, that way the @internal APIs are available and the typings property in the package manifest can just point to the trimmed rolled up .d.ts file.

I guess to truly be as close from metal as possible you could go one step further and publish all your packages to a fake registry (for example a Verdaccio instance). That would trigger the full pack pipeline, including publishConfig.main replacement.

Another alternative would be to make a hook (beforeWorkspacePacking) that would have the ability to modify the manifest at publish-time. This would actually be interesting, because I had to duplicate the main and module logic for both pack and publish (since each of them require to transform the manifest independently) - this would give us a way to avoid doing that.

from berry.

I guess to truly be as close from metal as possible you could go one step further and publish all your packages to a fake registry (for example a Verdaccio instance). That would trigger the full pack pipeline, including publishConfig.main replacement.

Fair point, but how would that work with our tests that are contained within the workspace?

Another alternative would be to make a hook (beforeWorkspacePacking) that would have the ability to modify the manifest at publish-time.

I was thinking along the same lines, because it doesn't make sense to have to duplicate this between pack and publish. I was also wondering whether this should be part of the core or a separate plugin altogether. I'm leaning towards a separate plugin, which could also do the main and module change.

from berry.

This hook would also be useful for #133.

from berry.

(I don't understand why but my first post appears at the bottom of this thread which is pretty annoying. Github probably messed up a date somehow 😔)

Fair point, but how would that work with our tests that are contained within the workspace?

Solvable with a dedicated infra (you could run the tests from your workspaces that would access the dependencies from your remote registry), but probably a fair amount of work for a low impact 🤔

I was also wondering whether this should be part of the core or a separate plugin altogether. I'm leaning towards a separate plugin, which could also do the main and module change.

I think main and module might be things we would want to have in plugin-essentials (because they have a far-reaching impact, particularly main which is recognized by Node), and types could be defined by plugin-typescript. Does that sound reasonable?

from berry.

Looks like they fixed it. Yesterday when I added my comments the OP and your comment were shown as "commented 3 hours from now" so they definitely messed up the dates.

I think main and module might be things we would want to have in plugin-essentials (because they have a far-reaching impact, particularly main which is recognized by Node), and types could be defined by plugin-typescript. Does that sound reasonable?

Sounds reasonable!

from berry.

Fixed by #148 👍

from berry.

I'm going to implement this in pnpm as well. This is an awesome feature!

from berry.