cargo fullstack issues on Windows

[XBagon]

After following the instruction to the point where I used cargo fullstack I encountered this:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: NotFound, message: "program not found" }', .cargo/bin/fullstack.rs:17:10

I found out the problem probably has to do something with this:

〉which yarn
╭───┬──────┬──────────────────────────────────┬──────────╮
│ # │ arg  │               path               │ built-in │
├───┼──────┼──────────────────────────────────┼──────────┤
│ 0 │ yarn │ C:\Program Files\nodejs\yarn.CMD │ false    │
╰───┴──────┴──────────────────────────────────┴──────────╯

After some research I found some fitting issues..
#issuecomment-368300622
rust-lang/rust#94743

For now the only idea I have to fix this, would be some Windows specific code to check for .CMD or maybe use which, which should support that?

[mayhemdot]

This problem can be easily fixed by adding the .cmd extension.
In addition to that, the yarn install location has to be added to the PATH environment variable.

#[cfg(windows)]
pub const YARN: &'static str = "yarn.cmd";

#[cfg(not(windows))]
pub const YARN: &'static str = "yarn";

Command::new(YARN)

Another problem is that Command::new("..").arg("fullstack") calls cargo tsync instead of tsync -i .. -o ...
It's probably a cargo bug because calling the .exe directly works fine and gives expected results.

One way to fix this is to change the [[bin]] section in Cargo.toml

[[bin]]
name = "tsync"
path = ".cargo/bin/tsync.rs"

[lynn]

The problem with tsync is that when yarn is invoked from cargo tsync, the PATH has more stuff on it and prioritizes the wrong binary named "tsync":

C:\code\my-create-rust-app\.cargo\.build\debug\deps\tsync.exe  // wrong one, not normally on PATH
C:\code\my-create-rust-app\.cargo\.build\debug\tsync.exe       // wrong one, not normally on PATH
C:\Users\lynn\.cargo\bin\tsync.exe                             // right one

(I got this by modifying the yarn script in package.json to "tsync": "where tsync && tsync -i ...")

So instead of yarn actually calling tsync, it calls cargo tsync again, recursing until it gets confused and dies:

Running `yarn tsync` in `$project_dir/frontend/`...
yarn run v1.22.15
$ tsync -i ../backend -o ./src/types/rust.d.ts
Running `yarn tsync` in `$project_dir/frontend/`...
$ tsync -i ../backend -o ./src/types/rust.d.ts
Running `yarn tsync` in `$project_dir/frontend/`...
$ tsync -i ../backend -o ./src/types/rust.d.ts
Running `yarn tsync` in `$project_dir/frontend/`...
$ tsync -i ../backend -o ./src/types/rust.d.ts
Running `yarn tsync` in `$project_dir/frontend/`...
...

I can't think of a good fix. Maybe we can call %USERPROFILE%\.cargo\bin\tsync explicitly somehow?

The fix @mayhemdot seems to hint at is to rename the wrapper under [[bin]] to something else (like "teesync" 😄):

  [[bin]]
- name = "tsync"
+ name = "teesync"
  path = ".cargo/bin/tsync.rs"

Now delete .cargo\.build\debug\deps\tsync.exe and .cargo\.build\debug\tsync.exe, and run cargo run --bin teesync instead of cargo tsync.

[AnthonyMichaelTDM]

These issues were fixed in #128 and #66

closing, feel free to re-open if it's still a problem