Add pnpm resolve plugin

[devchakraborty]

Summary

In pnpm, unlike other package managers, by default dependencies are not hoisted to the highest node_modules folder possible. As a result, on pnpm the admin UI is unable to build; the copied source in the apos-build folder is not able to resolve its transitive dependencies.

This PR adds a plugin that helps module resolution in a pnpm context. Given a list of direct dependency packages, it searches those packages' dependencies as needed. This should be a no-op outside pnpm because vite and rollup get a chance to resolve the module first; hoisted dependencies will always be found before this plugin searches elsewhere.

What are the specific steps to test this change?

1. Run the backend and ensure the build succeeds (especially the admin UI build) when running with pnpm.

What kind of change does this PR introduce?

• Bug fix
• New feature
• Refactor
• Documentation
• Build-related changes
• Other

Make sure the PR fulfills these requirements:

• It includes a) the existing issue ID being resolved, b) a convincing reason for adding this feature, or c) a clear description of the bug it resolves
• The changelog is updated
• Related documentation has been updated
• Related tests have been updated

Other information:

• Please provide guidance on what version this change should be a part of so I can update the changelog accordingly.
• I wasn't sure what documentation should be updated for this change, let me know of any suggestions.
• The existing tests pass and I think setting up a pnpm context for a test would be a big lift, but let me know if you feel that's necessary.

[ValJed]

Hello @devchakraborty,

I think that a better approach than reworking the apos vite plugin would be to use the pnpm public-hoist-pattern feature that allow to hoist only the packages you need.

Here is an example of a .npmrc file to put at the root of your project, (can be added in the package.json I think too):

public-hoist-pattern[]=*eslint*
public-hoist-pattern[]=*apostrophe*
public-hoist-pattern[]=vue-advanced-cropper

This will hoist eslint packages (if needed by IDEs), all packages with a name starting with @apostrophecms, and also vue-advanced-cropper because we import files directly (css files) not allowed by pnpm strict mode.

With this config you'll be able to run you apostrophe project, I just tested it :)

Another advice for pnpm, you can configure allowed lib that perform postinstall scripts, for apostrophe you might need sharp (config to put in the package.json):

  "pnpm": {
    "onlyBuiltDependencies": [
      "sharp"
    ]
  }

[devchakraborty]

Hi @ValJed - adding apostrophe packages to the public hoist pattern for pnpm does not fix the build for us because it is the transitive dependencies that we are failing to resolve, not the apostrophe packages themselves. My build error on pnpm v10 is:

[vite]: Rollup failed to resolve import "tiny-emitter/instance" from "/path/to/project/apos-build/@apostrophecms/vite/default/src/apos.js".

Hoisting tiny-emitter only reveals the next transitive dependency in the error. Hoisting all the transitive dependencies might fix the problem, and we started to explore this, but this ended up being a very long list of dependencies. We could also enable shamefully-hoist to hoist everything, but this would defeat the point of pnpm and wouldn't be acceptable in our monorepo. Hence this more complicated plugin idea.

[ValJed]

@devchakraborty Ok I see, I can reproduce the problem with a pnpm monorepo indeed.
We would like to be able to get rid of this need for hoisting however this is a certain amount of work.
I agree hoisting works well, it's still symlinks but it defeat pnpm safety indeed.
Could be a temporary solution.

[myovchev]

@devchakraborty I'd like to test the change first before discuss it with you (and look closely at the implementation you offer).
On a first glance, I'm concerned about specific (in some case - legacy) alias resolution. I'd need some time to switch on that one (few days probably).

[devchakraborty]

Hi @myovchev, any updates? We have applied this change as a pnpm patch internally so we are no longer blocked, but we would prefer not to have this patch around indefinitely. Hoisting is not a sustainable option in our monorepo either.

[ValJed]

Hey @devchakraborty sorry for the lack of udpates. @myovchev isn't available these days, he is responsible for this module so it's better if he takes care of it. Should be pretty soon, cool it's not a blocker for you!!

[myovchev]

Hi @myovchev, any updates? We have applied this change as a pnpm patch internally so we are no longer blocked, but we would prefer not to have this patch around indefinitely. Hoisting is not a sustainable option in our monorepo either.

Hey @devchakraborty, sorry for the delay. I'm back and I'll be working on this one now.

[myovchev]

@devchakraborty This is a good base but can't be a complete solution due to many missing (and failing) parts. I decided to create a separate branch that builds upon your idea, but also adds some internals and handles edge cases (e.g. configurations, defaults, changelog, docs) - #23

I also created a playgrounds based on our vite-demo repo. In the PR details, among detailed explanations about what we should add as a solution and maintain in the future, are also details about how to run the change against pnpm simple demo project and pnpm workspace project (aka monorepo).

Please look closely at the PR, do tests and experiment in your own setup and environment to see if it behaves as expected. We can collborate further how we proceed with the final contribution after that.