Closed mastermind-0xff closed 1 year ago
Thank you for submitting the issue. To help us resolve this issue, could you please share the following points?
D
and drive C
is detected by mistake?Thanks for providing more information. I was able to reproduce the problem, so I will first describe the steps to reproduce it.
npx @wordpress/create-block test-block
mklink /d test-block-symlink test-block
cd test-block-symlink
robocopy /move src src\block-a & xcopy src\block-a\ src\block-b\
rmdir /s build
npm run build
build/
├── block-a/
│ └── block.json
└── block-b/
└── block.json
Skipping "./index.js" listed in "path/to/test-block-symlink/src/block-a/block.json". File is located outside of the "src" directory.
Skipping "./index.js" listed in "patj/to/test-block-symlink/src/block-b/block.json". File is located outside of the "src" directory.
No entry file discovered in the "src" directory.
Then this is the test result on WSL (Ubuntu). This one works correctly.
npx @wordpress/create-block test-block
ln -s test-block test-block-symlink
cd test-block-symlink
mkdir src/block-a; mv src/*.js src/*.scss src/*.json src/block-a/; cp -r src/block-a src/block-b
rm -rf build
npm run build
Confirm that all files are generated in the build directory correctly without error messages.
I have found one clue.
The results of fast-glob
are different between Windows and Linux.
blockMetadataFiles
returns an array of simlink paths on Windows and an array of resolved paths on Linux.
As a result filepath is the symlink path while the srcDirectory is the resolved path. Not sure what the reason for realpathSync ussage is, but I guess it should be investigated.
realpathSync
resolves symbolic paths, which I believe is the expected implementation. I think the problem is that the filepath
(i.e., the one generated from blockMetadataFiles
) is a simlink path.
Once I do, I may need to look into how fast-glob
is resolving the shimlinks.
I encountered this problem when developing plugins on a Windows machine where the plugin code is stored in a "global" directory and symlink'd into a particular WP site.
blockMetadataFiles
returns an array of simlink paths on Windows and an array of resolved paths on Linux.As a result filepath is the symlink path while the srcDirectory is the resolved path. Not sure what the reason for realpathSync ussage is, but I guess it should be investigated.
I can confirm both of the above (using WSL (CentOS7) for the linux testing).
I've looked at the PR in #54212, and have a suggestion for a simpler solution, that seems to work for me (both in Windows and linux), but there may be use cases that it doesn't account for.
in config.js
L236-239, adding a realpathSync()
call when constructing filepath
seems to solve the problem for me. That is, replacing:
const filepath = join(
dirname( blockMetadataFile ),
value.replace( 'file:', '' )
);
with:
const filepath = realpathSync( join(
dirname( blockMetadataFile ),
value.replace( 'file:', '' )
) );
@t-hamano can you confirm that this simpler solution works for you?
@pbiron, there is now a refactored version of #54212 that should resolve the same issue by standardizing the way it uses glob
calls. Can you confirm it resolves the issue for you? I'd like to land it as soon as I hear back from you.
@gziolo the latest PR works great for me in Windows, whether I run the scripts from the dir that is symlink'd or the target dir.
thanx!
Hi guys!
When trying to build multiple blocks I got the following error:
Some investigation led to "...\@wordpress\scripts\utils\config.js" line 256:
and "...\@wordpress\scripts\utils\package.js" line 12:
As a result
filepath
is the symlink path while thesrcDirectory
is the resolved path.Not sure what the reason for
realpathSync
ussage is, but I guess it should be investigated.Hope this saves someone's time. Cheers, Tony