After upgrade, the assets in other watchedFolders are not resolved correctly

Do you want to request a feature or report a bug?

A bug

What is the current behavior?

Images located in other watchedFolders are not resolved properly in react native after upgrade.

Upgrade details:

• React Native 0.57.1 => 0.57.7
• metro preset 0.45.3 => 0.49.2

The structure of my files looks like this:

 📂 affiny
 ├ 📂 affiny-app
 │ ├ 📂 assets
 │ │ └ 🖼 splashscreen.png
 │ └ 📂 src
 │   └ 📄 app.specific.stuff.ts
 ├ 📂 affiny-web
 │ ├ 📂 assets
 │ │ └ 🖼 web.specific.image.png
 │ └ 📂 src
 │   └ 📄 web.specific.stuff.ts
 └ 📂 affny-core
   ├ 📂 assets
   │ └ 🖼 not.specific.image.png
   └📂 src
     └ 📄 not.specific.stuff.ts

and I have a rn-cli:

const path = require('path');

module.exports = {
  watchFolders: [
    path.resolve(__dirname, '../affiny-core'),
  ],
};

Before upgrade, i can do:

<Image src={require('affiny-app/assets/splashscreen.png')} />

and

<Image src={require('affiny-core/assets/not.specific.image.png')} />

After upgrade, i can do:

<Image src={require('affiny-app/assets/splashscreen.png')} />

but image in my-project-core, eg:

<Image src={require('affiny-core/assets/not.specific.image.png')} />

are resulting in a gray screen:

What is the expected behavior?

Either:

• no regression, everything working as before.
• a deprecation documented so I can adapt my code

Investigation

I added a breakpoint here:

Before the upgrade, the packager url for assets was:

resolver.defaultAsset().uri;
// -> "http://localhost:8081/assets/assets/img/profile_capture/search.jpg?platform=ios&hash=51dac229328bf5d045e9401cb6cb3cb4"

after the upgrade:

resolver.defaultAsset().uri;
// -> "http://localhost:8081/affiny-core/assets/img/profile_capture/search.jpg?platform=ios&hash=51dac229328bf5d045e9401cb6cb3cb4"

Note above:

• “affiny-core” instead of “assets”

When asking for http://localhost:8081/affiny-core/assets/img/profile_capture/search.jpg?platform=ios&hash=51dac229328bf5d045e9401cb6cb3cb4, I get a 404.

Note that http://localhost:8081/assets/assets/img/profile_capture/search.jpg?platform=ios&hash=51dac229328bf5d045e9401cb6cb3cb4 works on both old RN/metro and new RN/metro.

Idea

Seems like https://github.com/facebook/metro/commit/ea980fd821abae27218dc1a4a3a0b9e454958bfd#diff-71293ea379a7cf006cd4648701a7c568 (https://github.com/facebook/metro/pull/299) is the root cause.

Maybe the RN packager is not aware of the public path.

Reproduction steps

I think it is a bit involving to do a repro here. Maybe you will have an idea with above investigation, else I will spend time doing a repro.

Configuration

Node: v8.11.3 React Native: 0.57.7 Metro: 0.49.2

[Kudo]

In my case, to the watchFolder resides out of projectRoot. Even the metro server accepts the request like. http://localhost:8081/assets/../../../common/assets/images/image.png

The RN Android image system uses okhttp to send requests. okhttp seems to prune the request as http://localhost:8081/common/assets/images/image.png Let’s why 404 happens.

My folder structure is pretty much like @tychota. Environment: RN 0.57.7, metro 0.48.3

Well, there is a dirty workaround for me. To create a symbolic link in current project root to the shared folder. ln -s ../../../common # In my project root This seems make metro able to find files even without 0eaa74182 patch.

[rafeca]

Ok, I’ve been able to reproduce it, the issue was introduced in https://github.com/facebook/metro/commit/a711d73c1ce7c1ed0bc3393b8842b7621e6d3e69 😅

Thanks for the detailed explanation of the issue, it was very helpful to debug it 😃

Very soon we want to force all watch folders to be inside the project root of metro, this way Metro can safely use the project root as the root of the http server that provides the assets and this will fix this issue.

In order to make this change, we’ll change the meaning of the projectRoot, which will just be a common folder where all the different watchFolders reside (so it’s going to be a breaking change).

I’m gonna check now if there’s any short-term workaround to fix this issue in the meantime