Great - thanks @axinom-benjamin for the insight.

I guess I now have the right pointer. What we do is that we add the local node_modules/.bin folder to the PATH, but we assume that the global one is in the path. Apparently, it is not always given.

I’ll figure out a way to check that beforehand and potentially add it.

Thanks again for helping here! 🍻

Looks like this is windows only, ran in WSL (Ubuntu) and the scaffold worked just fine.

@FlorianRappl Thanks for pointing that out, and I had to rework my fix. Spawning a child process still looks for the PATH property on the env options, so I made the change only for a Windows environment. See changes in PR https://github.com/smapiot/piral/pull/444

Our organization has just started looking into piral as an alternative microfrontend framework.

We encountered a possibly-related issue where, in some environments, the piral build also had a problem finding the npm command during the packaging step of the piral instance.

Tracked it down to a Windows environment where nodejs is not installed in the standard location because it was installed as non-administrator. In this case, npm.cmd was installed in some path like C:\Users\USER\apps\nodejs and that path is added to the Windows PATH environment variable.

As discovered in https://github.com/smapiot/piral/issues/192#issuecomment-615106475, the scripts.ts code is incorrectly using the env object Path property because of case-sensitivity as described in https://github.com/nodejs/node/issues/20605

Fixed it in scripts.ts with the following (changing all env.PATH to env.Path):

export function runScript(script: string, cwd = process.cwd(), output: NodeJS.WritableStream = process.stdout) {
  const bin = resolve('./node_modules/.bin');
  const sep = isWindows ? ';' : ':';
  const env = Object.assign({}, process.env);

  env.Path = `${bin}${sep}${env.Path}`;
  log('generalDebug_0003', `Running "${script}" in "${cwd}" ("${bin}").`);

  if (isWindows) {
    // on windows we sometimes may see a strange behavior,
    // see https://github.com/smapiot/piral/issues/192
    const newPaths = [
      resolveWinPath('AppData', 'npm'),
      resolveWinPath('ProgramFiles', 'nodejs'),
      resolveWinPath('ProgramFiles(x86)', 'nodejs'),
      ...env.Path.split(';'),
    ];
    env.Path = newPaths.filter(Boolean).join(sep);
  }
  ...

I’d like to initiate a PR, but I get failures on the latest develop branch on building piral-cli-webpack5.

still the same after npm cache clean --force

But I agree that this issue is not worth hunting further. It sees not really wide-spread and most likely some strange configuration that is happening on my machine. Since there are also very feasible workarounds, so it’s not a critical issue at all.

The workarounds (that work on my machine) for the protocol:

• Running from actual Powershell rather than the integrated VS Code terminal works
• Running from global installation works
• Running from local installation through npm scripts work

The only thing that doesn’t work is: running it using npx from inside the integrated terminal in VS Code.

Still, thanks for all the time spent trying to find the issue!

no news, unfortunately - working around it by not using the integrated terminal for the CLI.

not sure if it helps anything, but the issue is not happening when using the integrated (bash) terminal of my WSL.

I guess it may be due to the way the options are provided. But then not sure why it works in one PS and not in the other. I would expect some issue, e.g., with CMD.

Definitely interesting … Thanks for the investigation so far! 🍻

I did some more tries and it’s working for me when I use PowerShell directly, but it fails when I run it from the Visual Studio Code integrated PowerShell. The output on the integrated PowerShell is:

PS C:\tmp\piral> piral new --target app-shell
- Preparing source and target ...null
Codes Reference: https://docs.piral.io/code/search

It created the app-shell folder but it only contains a package.json, nothing more.