Scaffolding a Piral Instance Fails in Windows

[MattShrider]

Bug Report

For more information, see the CONTRIBUTING guide.

Prerequisites

• Can you reproduce the problem in a MWE?
• Are you running the latest version?
• Did you perform a search in the issues?

Environment Details and Version

[email protected]
Windows

Description

Trying to follow the tutorial#1 getting started, says to run piral new --target my-app, following this fails to run. It gives me a blank folder with a package.json and nothing else.

Steps to reproduce

$ piral new --target app-shell
> Codes Reference: https://docs.piral.io/code/search

Expected behavior

There should be a new piral instance there with the correct template

Actual behavior

The folder was empty and piral debug fails.

Possible Origin / Solution

The tutorials may be out of date?

[MattShrider]

As a follow up https://docs.piral.io/ seems to say that you should instead use npm init piral-instance, which DOES work, so this is probably just outdated tutorial pages.

[FlorianRappl]

As a follow up https://docs.piral.io/ seems to say that you should instead use npm init piral-instance, which DOES work, so this is probably just outdated tutorial pages.

npm init piral-instance uses piral new under the hood. The latter is just a pure CLI UX with parameters while the former places a survey upfront to walk through the different options.

So both things should work - and the tutorial is not outdated even though we recommend using npm init for a couple of reasons.

I've just tried this in WSL and for me this worked. What version of the piral-cli did you install? Is 0.11.1 also the version of the Piral CLI?

rapplf@DBTNODH:/mnt/c/Users/flori$ piral --version
0.11.1
rapplf@DBTNODH:/mnt/c/Users/flori$ cd /mnt/e/Code/Piral-Playground/
rapplf@DBTNODH:/mnt/e/Code/Piral-Playground$ piral new --target my-app
✨  Successfully scaffolded new Piral instance!      
rapplf@DBTNODH:/mnt/e/Code/Piral-Playground$ cd my-app/
rapplf@DBTNODH:/mnt/e/Code/Piral-Playground/my-app$ ls
node_modules  package.json  src  tsconfig.json
rapplf@DBTNODH:/mnt/e/Code/Piral-Playground/my-app$ npm start

> [email protected] start /mnt/e/Code/Piral-Playground/my-app
> piral debug

⚡️  Running at http://localhost:1234.
⚙️  Manage via http://localhost:1234/manage-mock-server.

Maybe this is OS related. I'll try in plain Windows later!

Thanks for the report. I'll keep investigating.

[MattShrider]

Specifically, I was following https://docs.piral.io/tutorials/02-getting-started , so I should have @latest tag of piral-cli, which is [email protected]

[MattShrider]

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

[FlorianRappl]

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

Thanks for confirming. Will be fixed asap!
🍻

[FlorianRappl]

So far I'm unable to reproduce this on my Windows machine. I could find another bug with the verbose logging filename of Parcel's logger on Windows, which will be fixed.

I used:

• NPM v6.1.0
• Node v10.7.0

Executed the scaffolding in PowerShell.

[BenjaminSchwendner]

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.

[FlorianRappl]

Hm I just tried running from VS Code. Seems to be working so far. I'll try a few variations.

Mind sharing the Node / NPM version? Thanks!

[BenjaminSchwendner]

PS C:\tmp> node --version
v12.16.1
PS C:\tmp> npm --version
6.14.4
PS C:\tmp> code --version
1.43.2
0ba0ca52957102ca3527cf479571617f0de6ed50
x64
PS C:\tmp> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.18362.628
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.18362.628
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

[FlorianRappl]

I also updated my Node / NPM versions to match this. No success so far - it always works.

[BenjaminSchwendner]

I did some quick debugging and it seems like the promise in

piral/src/packages/piral-cli/src/apps/new-piral.ts

Line 85 in 23e7fd9

await installPackage(packageRef, root, '--no-package-lock');

gets rejected with that error:

Error: null
    at ChildProcess.<anonymous> (C:\Users\schwendner\AppData\Roaming\npm\node_modules\piral-cli\lib\common\scripts.js:24:75)
    at ChildProcess.emit (events.js:323:22)
    at maybeClose (internal/child_process.js:1021:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:286:5)

though it doesn't really give any hints why the install failed...

[FlorianRappl]

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! 🍻

[MattShrider]

I'm running in node v10.14.2 and npm 6.4.1 for more info.

[FlorianRappl]

Still having trouble to reproduce.

For me - no matter the Node and NPM version - it works. It works in PowerShell, works in PS of VS Code (Windows) and also works in plain CMD.

I have a feeling that the problem lies in this part

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}").`);

  return new Promise<void>((resolve, reject) => {
    const error = new MemoryStream();
    const opt = { end: false };
    const cp = exec(script, {
      cwd,
      env,
    });

    cp.stdout.pipe(output, opt);
    cp.stderr.pipe(error, opt);

    cp.on('error', () => reject(new Error(error.value)));
    cp.on('close', (code, signal) => (code === 0 ? resolve() : reject(new Error(signal))));
  });
}

but I don't know which part could be responsible.

I will actually defer this issue to 0.11.3 - and I hope that in the meantime it can be reproduced. Thanks for the infos and efforts so far @MattShrider @axinom-benjamin !

[BenjaminSchwendner]

PS C:\Projects\PiralTest> npx piral-cli@next new --target app-shell
- Preparing source and target ...Der Befehl "where.exe" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
Codes Reference: https://docs.piral.io/code/search
PS C:\Projects\PiralTest> npx piral-cli@next new --version
0.11.6-pre.1372

still the same

[FlorianRappl]

Hm something does not seem right. The latest next version does not come with any usage / lookup for where.exe.

[BenjaminSchwendner]

that's strange indeed...
one more thing to note: I see this issue only when running through npx or running piral from the global installation.
When running npm i piral-cli (only locally installed) first and then executing it from a npm script it will succeed - even with 0.11.5.

and when installing @next globally and running the new command I get now this:

PS C:\Projects\PiralTest> piral new --target app-shell
- Preparing source and target ...Der Befehl "npm.cmd" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
Codes Reference: https://docs.piral.io/code/search
PS C:\Projects\PiralTest> piral --version
0.11.6-pre.1372

[FlorianRappl]

Understood. Thanks for the investigation @axinom-benjamin !

One more try please (...). Thanks!

[BenjaminSchwendner]

PS C:\Projects\PiralTest> npx piral-cli@next --version
0.11.6-pre.1380
PS C:\Projects\PiralTest> npx piral-cli@next new --target app-shell
- Preparing source and target ...Der Befehl "npm.cmd" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
Codes Reference: https://docs.piral.io/code/search

😟

[FlorianRappl]

Since we cannot reproduce it I would suggest to try npm cache clean --force if this has any impact.

We'd now defer that back to an unknown point in time. Its not a critical issue and it seems to be difficult / very special to reproduce. At least we have not managed to see it on our Windows machines.

Once a solid path for reproduction is known we can look into this again.

[BenjaminSchwendner]

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!

[Robbson]

I get the same issue when using Powershell inside VS Code on my dev machine at work.
In comparison to a standalone Powershell terminal the environment seems partially different.

But it's not an issue for me because I don't use it there.
Just to inform you that I can reproduce it here.

[FlorianRappl]

Tried in VS Code on my Windows host. I tried piral new (global installation) npx piral new (using npx task runner) and npm init piral-instance -y. All worked.

I am therefore unsure to proceed. I'd love to close (fix) this, but without having a reproducible on my machine it will be difficult. I am quite sure its something about the ENV, but I don't know what.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[peter-at-work]

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 #192 (comment), the scripts.ts code is incorrectly using the env object Path property because of case-sensitivity as described in nodejs/node#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.

[FlorianRappl]

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

Yeah just do the PR (much appreciated!) - we can handle the build failure separately!

[FlorianRappl]

(I also need to point out that we need to be careful here. process.env.PATH is not process.env.Path. On Linux you'd get undefined in the latter case. I think we need to distinguish the OS here. And by the way, with Node 16 both ways also seem to work fine on Windows, so I'm not sure if that is indeed the issue / fix.)

[peter-at-work]

@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 #444