fix(remix-dev): yarn pnp compatibility plugin

[lensbart]

Swaps out @yarnpkg/esbuild-plugin-pnp (which did not work nicely with @esbuild-plugins/node-modules-polyfill) for @esbuild-plugins/node-resolve (which is from the same repo as the latter).

• Also silences a harmless error when yarn config get @remix-run:registry throws because the setting can’t be found

• fix(remix-dev): fix config call when using Yarn PnP #3566 intended to achieve the same effect, but was less effective, so I closed that PR.

• fix(remix-dev): fix Yarn PnP resolve issue #3579 did not do the trick for me, and the plugin ordering seems not to matter with the new plugin, but it could be that @alisd23’s setup is different, so I left a comment about the plugin ordering just in case.

• Probably should be tested by other people as well, given that previous fixes were brittle.

• Interferes with fix(remix-dev): relativize route modules to make builds deterministic #2027, not sure which approach is preferable

[remix-cla-bot]

Hi @lensbart,

Welcome, and thank you for contributing to Remix!

Before we consider your pull request, we ask that you sign our Contributor License Agreement (CLA). We require this only once.

You may review the CLA and sign it by adding your name to contributors.yml.

Once the CLA is signed, the CLA Signed label will be added to the pull request.

If you have already signed the CLA and received this response in error, or if you have any questions, please contact us at [email protected].

Thanks!

- The Remix team

[remix-cla-bot]

Thank you for signing the Contributor License Agreement. Let's get this merged! 🥳

[MichaelDeBoey]

Can you explain the reasoning behind creating our own plugin instead of using the official one by the Yarn team please?

If changes to the plugin are needed, why don't we create a PR upstream for it?

[lensbart]

This is just an instantiation with default config according to the @esbuild-plugins/node-resolve docs because it’s being used in two places in this file.

I’ve tried using both the previous plugin and this one, and this is the only one that works for me, hence the change.

I haven’t looked into what to fix in the other plugin in order to get it to work.

[MichaelDeBoey]

I understand that this works, but I rather would keep using the official Yarn PnP plugin & create a fix upstream instead of running with our own version (and the burden of maintaining that ourselves) tbh.

Could you please create a compact reproduction repo & file an issue upstream?
That way we can first look on what's the problem on their end & maybe we can fix it in our repo with just a dependency update & without any extra maintenance.

[lensbart]

I’ll take a look over the weekend. (Although I still don’t quite understand how this increases our maintenance burden — the plugin is maintained here and is designed specifically for PnP compatibility.)

[MichaelDeBoey]

It's not a big difference, but now we just import the official Yarn PnP plugin and that's it.

With your solution, we have to know the API (& options) of the @esbuild-plugins/node-resolve plugin.
If they ever have a breaking change in there, it adds extra maintenance work on our side.

An API-less plugin won't have any impact then.

[alisd23]

@lensbart Out of interest, a couple of questions, to see if we can work out why the results are different for us.

• When you say the fix(remix-dev): fix Yarn PnP resolve issue #3579 fix didn't do the trick, were you getting the same errors as I mentioned in that PR, or different ones?
• What Remix versions were you using? I was using the nightly version (just after your initial fix was merged)
• Are you using yarn workspaces (like I was)? And is there anything special in your setup that you can think of?

I'll also aim to try the plugin you're suggesting in this PR, to see what results I get.

[lensbart]

@alisd23 I think my issues are mainly with choosing Deno as a target (via yarn create remix).

• I was using the v0.0.0-nightly-1e32bfa-20220622 branch from feat(remix-dev): add support for Yarn 3 PnP #1316. (Henceforth I’ll just be using the latest version, because these changes have been released in the meantime.)
• I’m indeed using Yarn workspaces in a monorepo setup. Nothing exotic comes to mind.

Reproduction: run yarn create remix with the following options

• Where would you like to create your app? → my-remix-app
• What type of app do you want to create? → Just the basics
• Where do you want to deploy? Choose Remix App Server if you're unsure; it's easy to change deployment targets. → Deno
• TypeScript or JavaScript? → TypeScript
• Do you want me to run yarn install? → n because it will fail

cd my-remix-app
yarn set version stable
touch yarn.lock
echo "nodeLinker: pnp" > .yarnrc.yml
yarn

I’d say an empty yarn.lock file should be generated by the CLI (in case the user is using Yarn), because without it, Yarn doesn’t even recognise the folder to be a project and running yarn install fails. (But before it can even fail due to missing lock file, it fails on yarn config get @remix-run:registry.)

Using this setup, yarn build fails. The error output is a bit too verbose to paste here, but the first error looks like

Building Remix app in production mode...
The path "@remix-run/deno" is imported in server.ts but @remix-run/deno is not listed in your package.json dependencies. Did you forget to install it?

✘ [ERROR] [plugin @yarnpkg/esbuild-plugin-pnp] Qualified path resolution failed: we looked for the following paths, but none could be accessed.

Source path: /some-folder-lol/readable-stream/duplex.js
Not found: /some-folder-lol/readable-stream/duplex.js
Not found: /some-folder-lol/readable-stream/duplex.js.tsx
Not found: /some-folder-lol/readable-stream/duplex.js.ts
Not found: /some-folder-lol/readable-stream/duplex.js.jsx
Not found: /some-folder-lol/readable-stream/duplex.js.mjs
Not found: /some-folder-lol/readable-stream/duplex.js.cjs
Not found: /some-folder-lol/readable-stream/duplex.js.js
Not found: /some-folder-lol/readable-stream/duplex.js.css
Not found: /some-folder-lol/readable-stream/duplex.js.json


    node-modules-polyfills:stream:4:21:
      4 │ import {Duplex} from './readable-stream/duplex.js';
        ╵                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This problem gets resolved by swapping out the Yarn plugins.

[jenseng]

I haven't looked into the specifics of what might be happening with Deno here, but I did fix another bug in esbuild-plugin-pnp around how it resolves relative paths (as part of getting #2027 passing again 😅 ), and the fix here might be similarly straightforward.

If you do go that route, here are a couple pointers:

• All the logic is contained in index.ts ... might be a matter of further refining the effectiveImporter logic or passing additional context to pnpApi.resolveRequest
• It's pretty straightforward to set up a simple integration test, which can be run locally to help you quickly repro and validate your fix (see here)

[alisd23]

@alisd23 I think my issues are mainly with choosing Deno as a target (via yarn create remix).

OK Interesting, that is a little more complex than my set up.

Also I've spent a bit more time actually (many hours) playing around with my Remix app with these fixes, and actually neither my original quick fix (re-ordering), or the changes in this PR have fixed the issue for me. Yarn PNP seems like a bit of a minefield at the moment. Will try to look into more detail soon.

[MichaelDeBoey]

@lensbart Is this still necessary now that #3633 is merged?

[lensbart]

Thanks for the reminder. I think not!