39

On the way of installing Webpack on my React Project, the following problem hinders my progress:

last step to configure the Webpack

npm run build && node ./dist/main.js

Error on Windows Power Shell / on Visual Studio Code

PS C:\Users\pythonbuddha\Desktop\to_experiment\to-do-list> npm run build && node ./dist/main.js
At line:1 char:15
+ npm run build && node ./dist/main.js
+               ~~
The token '&&' is not a valid statement separator in this version.
    + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : InvalidEndOfLine

Tutorial which promised to configure the webpack

https://developerhandbook.com/webpack/webpack-4-from-absolute-scratch/

https://developerhandbook.com/webpack/how-to-configure-scss-modules-for-webpack/
mklement0
  • 312,089
  • 56
  • 508
  • 622
pythonbuddha
  • 706
  • 2
  • 8
  • 17

5 Answers5

52

It's because you're in PowerShell, try running it in CMD or Git Bash

Alternatively (if you wish to continue in PS):

(npm run build) -and (node ./dist/main.js)

3rd Alternative, just run them separetly,

Tibebes. M
  • 5,841
  • 4
  • 12
  • 34
  • 1
    it worked for command line issue but created issue related to React. – pythonbuddha Jan 08 '21 at 11:08
  • 3
    Good point about a different command being needed in Windows PowerShell (though no longer in PowerShell (Core) 7+), but it is important to note that PowerShell's `-and` and `-or` operators are _not_ replacements for `&&` and `||` - they function fundamentally differently, effectively discarding stdout output and returning a single Boolean instead - see the bottom section of [this answer](https://stackoverflow.com/a/41816341/45375). – mklement0 Mar 23 '21 at 13:51
  • 1
    I'd argue that mentioning the `-and` alternative is a bit misleading as I doubt people would normally want what `-and` does (I certainly did not want that and only realised this when my command was running). The answer should just mention that to achieve the same in Powershell use PowerShell version 7+. – István Siroki Oct 26 '21 at 15:32
19

I found that within PowerShell as my terminal within VS Code, replacing && in the command with ; did the trick.

Toni
  • 1,495
  • 4
  • 13
  • 22
Sam Patankar
  • 307
  • 2
  • 2
  • `;` is the statement separator in PowerShell, resulting in _unconditional_ sequencing of commands, analogous to `&` in `cmd.exe` - this is _not_ the same as `&&`, which only executes the RHS command _if the LHS command succeeded_. – mklement0 Apr 26 '22 at 20:26
16

PowerShell (Core) v7+ - but not Windows PowerShell - now does support && and ||, the pipeline-chain operators, so your command should work as-is there - see this answer for PowerShell-specific considerations for their use; see below for Windows PowerShell workarounds.

Conceptual note:

  • In all shells that support it (notably cmd.exe and POSIX-compatible shells such as Bash), && conditionally sequences commands: it executes its RHS command only if the LHS command indicated success; || is the inverse: it executes the RHS only if the LHS indicated failure.

  • This is important for preventing execution when it makes no sense to do so; e.g., in
    npm run build && node ./dist/main.js it only makes sense to run what was just built (with node) if the build succeeded, which is what && ensures.

Windows PowerShell workarounds:

The most succinct workaround:

npm run build; if ($?) { node ./dist/main.js }

This builds on the automatic $? variable, which is a Boolean indicating whether the most recent command succeeded.

The most robust workaround, needed if the commands use 2> redirections:

npm run build; if ($LASTEXITCODE -eq 0) { node ./dist/main.js }

Basing the success test on the automatic $LastExitCode variable, which reflects the process exit code of the most recently executed external program, avoids problems in Windows PowerShell[1] where the presence of stderr output in combination with redirecting it via 2> mistakenly sets $? to $false even when the process exit code is 0.


[1] The problems with 2> redirections are summarized in this answer. They also plague PowerShell (Core) up to version 7.1

mklement0
  • 312,089
  • 56
  • 508
  • 622
7

The && operator is used in linux bash to run both commands after each other. (Also if the first command fails, the second won't be executed)

This does not work in PowerShell on Windows so just split both commands and run them separately:

npm run build
node ./dist/main.js

For completeness, Powershell can behave the same when you do (command1) -and (command2) and && might actually work depending on your PowerShell version.

See this for further info: https://stackoverflow.com/a/564092/2232127

JensV
  • 3,788
  • 1
  • 19
  • 40
  • Running two commands in sequence _unconditionally_ (which you can do on the same line by using statement separator `;` in PowerShell) is _not_ the same as the `&&` operator. `-and` and `-or` in PowerShell work fundamentally differently and will more likely than not _not_ work as intended, as I've tried to show in the bottom section of [this answer](https://stackoverflow.com/a/41816341/45375). – mklement0 Apr 26 '22 at 20:40
  • I missed that your opening paragraph correctly describes `&&`. I suggest making it clearer that your PowerShell solution _acts differently_ - but note that a Windows PowerShell emulation of `&&` is readily available (and no longer needed in PowerShell v7+, where `&&` and `||` are now supported). – mklement0 Apr 27 '22 at 14:42
2

I have solved the issue by upgrading powershell and renamed dir. path folder name by removing spaces. Now it works properly.

Powershell upgradation link

https://github.com/PowerShell/PowerShell/releases/tag/v7.2.0-preview.8

  • Yes, as previously mentioned PowerShell (Core) versions 7.0 and above now support `&&` and `||`. It is unclear how spaces in folder names relate to this. Also, I suggest not using a link to an obsolete preview version of PowerShell. For users currently using the legacy, comes-with-the-OS _Windows PowerShell_ edition, switching to the cross-platform, install-on-demand _PowerShell (Core)_ edition is more than just an upgrade: it requires a very deliberate migration and the awareness that certain existing code may break. – mklement0 Apr 26 '22 at 20:46