Build package error on Windows: ENOENT: no such file or directory

[cvietor]

Issue

Cannot build plugins on Windows (10), as the build script fails with the following error message:

PS C:\Dev\_playground\plugin-workspace-test> npm start

> plugins@0.0.0 start C:\Dev\_playground\plugin-workspace-test
> nps

nps is executing `default` : nps-i
? NativeScript Plugins ~ made with ❤️  Choose a command to start... @testing.some-plugin.build      @testing/some-plugin: Build
nps is executing `@testing.some-plugin.build` : nx run some-plugin:build.all

> nx run some-plugin:build.all 

> nx run some-plugin:build 
ENOENT: no such file or directory, open 'C:\Dev\_playground\plugin-workspace-test\packages\package.json'
The script called "@testing.some-plugin.build" which runs "nx run some-plugin:build.all" failed with exit code 1 https://github.com/sezna/nps/blob/master/other/ERRORS_AND_WARNINGS.md#failed-with-exit-code
(node:4684) UnhandledPromiseRejectionWarning: Error: spawn nps @testing.some-plugin.build ENOENT
    at notFoundError (C:\Dev\_playground\plugin-workspace-test\node_modules\@nstudio\nps-i\node_modules\cross-spawn\lib\enoent.js:6:26)
    at verifyENOENT (C:\Dev\_playground\plugin-workspace-test\node_modules\@nstudio\nps-i\node_modules\cross-spawn\lib\enoent.js:40:16)
    at ChildProcess.cp.emit (C:\Dev\_playground\plugin-workspace-test\node_modules\@nstudio\nps-i\node_modules\cross-spawn\lib\enoent.js:27:25)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:272:12)
(node:4684) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:4684) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I also tried that on macOS, where it works like a charm.

Reproduction

1. Download a zip of this repo
2. Unzip and name the folder appropriately (perhaps the name of the npm scope you intend to manage here)
3. Setup workspace: npm run setup
4. Configure your npm scope: npm run config
5. Add a plugin package: npm run add
6. Execute build command: npm start -> select "@testing.some-plugin.build"

[hrueger]

@cvietor I have the same problem. Did you consider using WSL2 with a Ubuntu Distro? That works for me.

[cvietor]

@hrueger I tried that but also with no success. i did some more tests and realized now that if i started with powershell and then try to build a package with ubuntu@wsl2, it does not work. But when i download a fresh copy and repeat all steps in ubuntu, it works, so i suspect a path seperator problem in a schematic or shell script, but could not spot any in a quick glance.

Too bad that ubuntu@wsl2 is unbearingly slow (aka not usable) on my machine.

[hrueger]

@cvietor weird. Are you using the VSCode remote thing for WSL2? This is slow for me. But if I just navigate to /mnt/c/source/... in an ubuntu terminal and run the command there, it works and is quite fast.

[cvietor]

nope, just using it in windows terminal. i suspect my companies anti-virus software or something like that. but nevermind, that's my workstations's problem :-)

edit: actually, vscode remote wsl was a nice hint, that works like a charm for me, if i place the code INSIDE the linux file system.

[NathanWalker]

@cvietor I posted a PR to @hrueger 's plugin workspace with what I believe fixes the build.all issue on windows. This is the changeset:
https://github.com/SchoolSquirrel/nativescript-plugins/pull/47/files
Could you try @cvietor when get a chance just modifying your tools/scripts/build-finish.ts file in your workspace as seen in that PR? If that works for you as well I'll add a migration to 1.0.7 of plugin-tools which will auto update that file for others.

[cvietor]

thanks @NathanWalker, that does not work unfortunatly. should have mentioned that i already tried that.
the bug seems to be before the build-finish script (a simple console.log at line 18 in build-finish.ts is also not printed)
I'm willing to help, could you provide a little hint on where to look for the build scripts? i.e.
nx run some-plugin:build.all <- i'm struggling to find that build.all script

[NathanWalker]

workspace.json is heart of every workspace. the build.all, using that repo as example, is located here:
https://github.com/SchoolSquirrel/nativescript-plugins/blob/main/workspace.json#L115
There's a build.all target for every plugin in workspace. The purpose is to ensure that the standard build is executed in addition to any other custom (for example angular) build tooling is executed afterwards.
The commands executed for build.all run target are what is listed here:
https://github.com/SchoolSquirrel/nativescript-plugins/blob/main/workspace.json#L119

[NathanWalker]

I'm not familiar with Windows nowadays, honestly haven't used Windows in 15+ years at least (and don't have one anywhere around me), but would love your assistance in getting Windows working - My best guess is a path handler somewhere?

[cvietor]

Yes, i was wondering what exactly is being executed in that nx run :build.all
I'm not that familiar with nx, so i will do some reading there.
I just found the part which is causing the problem, but i don't have a solution yet.
If i change to "root" property in the workspace from:
"some-plugin": { "root": "packages/some-plugin", "sourceRoot": "packages/some-plugin",
to
"some-plugin": { "root": "packages\\some-plugin", "sourceRoot": "packages/some-plugin",

it works

[NathanWalker]

Interesting - there was a pr back in May to Nx for something similar to that:
nrwl/nx#2941

[jcassidyav]

Reverting to plugin-tools 1.0.5 allows the build to run for me.

[cvietor]

@NathanWalker it actually is exactly that mentioned problem.
in this scenario, the "all" project's root value in the workspace.json is causing this behaviour to fail on windows.

{
	"version": 1,
	"projects": {
		"demo": { ... },
		"demo-angular": { ... },
		"all": {
			"root": "packages", <----------- this here
			"projectType": "library",
			"architect": { ...

now when nx is building up the project graph and is trying to sort out the dependencies with that (in nrwl/nx#2941 mentioned) method:

  private findProjectOfResolvedModule(resolvedModule: string) {
    const importedProject = this.sortedWorkspaceProjects.find((p) => {
      return resolvedModule.startsWith(p.data.root);
    });

    return importedProject?.name;
  }

my index.android.ts is importing './common.ts', so "resolvedModule" is
packages\some-plugin\common
but that p.data.root is actually
packages/some-plugin

BUT "all" has a p.data.root of
packages

so "all" is returned as an imported project and for that reason ends up in the dependency graph of "some-plugin".
as a result of that, treated as a dependency, if will look for "/packages/packages.json".

changing

{
		"all": {
			"root": "packages", <----------- this here

to

{
		"all": {
			"root": "packages/"

prevents that, but does feel like a hack with unforseen side effects.
still not quite sure what a good solution this should look like

[NathanWalker]

@cvietor interesting find - Have you found that adding a slash to end of packages 100% fixes it on Windows though?
If so I'll make sure no side effect on Mac (don't believe there would be) and we'll update tooling to ensure a slash is always ending there.

[cvietor]

yes, that fixes it, as that resolvedModule.startsWith(p.data.root) evaluates to false then on the "all" project (which is good as "all" does not end up in the dependency graph).
the greater question is: "all" is only falsely picked as a dependency from the workspace projects because the actual projects data.root has forward instead of backward slashes, so the filter expression of the find method will never pick the right dependency. now the real question: could that cause issues? if the found project is the same as the resolvedModule, it gets filtered out anyway later on. and a nativescript plugin "package" should not reference another "package" directly.

i did a projectGraph comparison with and without the mentioned /:
windows:

• without / -> "all" ends up in dependencies
• with / -> no "all" in dependencies

ubuntu@wsl2:

• without / -> no "all" in dependencies
• with / -> no "all" in dependencies

so at least on linux side, that change does not cause any side effects. it's all quite complicated for a missing slash :-)

[NathanWalker]

Ha for sure. Thank you for help on this, I'll update tooling to ensure an ending slash is there and confirmed Mac is good with that as well so this should be good on Windows, Linux and Mac 👍 Will post back once update is out to resolve this.

[hrueger]

Works for me, too. Thank's @NathanWalker and @cvietor!