neon new and build failed on Node11.10.1 Win10

Created on 22 Apr 2019  路  9Comments  路  Source: neon-bindings/neon

Simple Installed Rust 1.34 stable. Node 11.10.1
Then execute like this

neon new my_project
Press ^C at any time to quit.
? version 0.1.0
? description
? node entry point lib/index.js
? git repository
? author Mario
? email [email protected]
? license MIT
^C缁堟鎵瑰鐞嗘搷浣滃悧(Y/N)? y // I wait for at least 30 minutes without any response. So I Ctrl C to Quit.

Then I execute like this

neon build

Then Got Error like this.
Compiling neon-runtime v0.2.0
error: failed to run custom build command for neon-runtime v0.2.0
process didn't exit successfully: C:\Work\Project\GoKart\CenterServer\Rust\rust_center\native\target\release\build\neon-runtime-b6860bb15546a35d\build-script-build (exit code: 101)
--- stdout
'Skipping node-gyp installation as part of npm install.'
audited 184 packages in 2.313s
found 1 high severity vulnerability
run npm audit fix to fix them, or npm audit for details
cargo:node_arch=x64

--- stderr
thread 'main' panicked at 'Couldn't find node_root_dir in node-gyp output.', src\libcore\option.rs:1038:5
note: Run with RUST_BACKTRACE=1 environment variable to display a backtrace.

neon ERR! cargo build failed

Error: cargo build failed
at Target. (C:\Users\lijh01\AppData\Roaming\npm\node_modules\neon-cli\lib\target.js:121:35)
at step (C:\Users\lijh01\AppData\Roaming\npm\node_modules\neon-cli\lib\target.js:32:23)
at Object.next (C:\Users\lijh01\AppData\Roaming\npm\node_modules\neon-cli\lib\target.js:13:53)
at fulfilled (C:\Users\lijh01\AppData\Roaming\npm\node_modules\neon-cli\lib\target.js:4:58)
at processTicksAndRejections (internal/process/next_tick.js:81:5)

I'm pretty sure that windows-built-tools is installed successfully.

bug needs investigation windows

All 9 comments

I have Node v10.15.3 + Rust 1.34.0 and i have exactly the same issue.
I've installed git because i supposed that it was important but no look so far.

Finally i give it up. It worked well on centOS.
I hope some day this problem will be solved.

I believe this is due to https://github.com/neon-bindings/neon/issues/409. Can you try this PR to see if it fixes the issue? https://github.com/neon-bindings/neon/pull/410

@kjvalencik Sorry, I am not OP, but no, that PR doesn't seem to fix it... See https://github.com/neon-bindings/neon/issues/352#issuecomment-524090836. Also, IMHO, I don't see how #409 relates to this issue.

I got the very similar situation in:

  • Windows 10 ( 64-Bit ) 10.0.19041.153
  • Node.js 13.5.0 / npm 6.13.4
  • Rust toolchain stable-x86_64-pc-windows-msvc / rustc 1.42.0 (b8cedc004 2020-03-09)
  • MSVS 2019 16.4.2 / cl 19.24.28314 for x64

And in now for temporary, I avoiding the situation using WSL2 environment. It work expectedly in the WSL2 GNU/Linux environment in:

  • Arch Linux / 4.19.84-microsoft-standard #1 SMP Wed Nov 13 11:44:37 UTC 2019 x86_64 GNU/Linux
  • Node.js 13.11.0
  • Rust toolchain stable-x86_64-unknown-linux-gnu / 1.42.0 (b8cedc004 2020-03-09)
  • gcc 9.3.0 / llvm 0.0.1

This problem will not be solved by users who simply try to use it, because there is no output on stdout or stderr. Is there anything I can do to help for NEON developers to solve the issue?

I tried attach the debbuger to cli source code:

  1. git clone [email protected]:neon-bindings/neon.git
  2. cd neon/cli
  3. code . ; I used VSCode as the debugger for this case
  4. modify tsconfig.json: compilerOptions.sourceMap: false -> true
  5. npm i
  6. npm run transpile
  7. write .vscode/launch.json:
{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Launch Program",
      "skipFiles": [ "<node_internals>/**" ],
      "program": "${workspaceFolder}\\bin\\cli.js",
      "args": [ "new", "zzz" ],
      "console": "integratedTerminal"
    }
  ]
}
  1. Launch in VSCode with Node.js debugger
  2. Probe the point what lost the control in .ts source code then:

image

The problem occur in console.log() line. It be no problems at the previous line ( the variable relativeRust is set "zzz\native\src\lib.rs" that is the expected value ).

But, I'm not an expert wizard of Node.js or TypeScript then I cannot sense a matter of the problem from the situation such as a lost control in console.log(). Does anyone have any idea of the situation?

I tried more debugging and got these hints:

  1. Comment these await filesystem APIs before 211: console.log(); then the process could be completed. It is an expected behavior.
  // await mkdirs(lib);
  // await mkdirs(src);

  // await writeFile(path.resolve(root,    '.gitignore'),   (await GITIGNORE_TEMPLATE)(ctx), { flag: 'wx' });
  // await writeFile(path.resolve(root,    'package.json'), (await NPM_TEMPLATE)(ctx),       { flag: 'wx' });
  // await writeFile(path.resolve(native_, 'Cargo.toml'),   (await CARGO_TEMPLATE)(ctx),     { flag: 'wx' });
  // await writeFile(path.resolve(root,    'README.md'),    (await README_TEMPLATE)(ctx),    { flag: 'wx' });
  // await writeFile(path.resolve(root,    answers.node),   (await INDEXJS_TEMPLATE)(ctx),   { flag: 'wx' });
  // await writeFile(path.resolve(src,     'lib.rs'),       (await LIBRS_TEMPLATE)(ctx),     { flag: 'wx' });
  // await writeFile(path.resolve(native_, 'build.rs'),     (await BUILDRS_TEMPLATE)(ctx),   { flag: 'wx' });
  1. If I uncommented any of commented line from (1) then the problem be occured.

Then, I think the matter is implementation of ../async/fs. It can be replace to the current fs or fs.promises module and it will be solve the problem. But it is using a very old modules since years then that work is so hard maybe. I'll try the fixing, wait a ... more hours.

Well, fixing and PR are done! 馃帀 #501

Summary at now

  1. This problem not happens when user using:

    • Node.js-8.17.0 ( 2020-03-27 by @usagi )

    • Node.js-9.11.2 ( 2020-03-27 by @usagi )

  2. This problem happens when user using:

    • Node.js-10.18.1 ( 2020-03-27 by @usagi )

    • Node.js-11.10.1 ( 2019-04-23 by @nemoNoboru )

    • Node.js-11.10.1 ( 2019-04-22 by @moriyalb )

    • Node.js-13.5.0 ( 2020-03-21 by @usagi )

And,

  1. Maybe, this problem happens from...:

    • STDOUT ( console.log ) when using at the same process...:



      • with fs and require('rsvp').denodeify ( because it not happens if comment these await lines in cli/src/ops/neon_new.ts )


      • with STDIN via inquirer ( because it happens only neon new )



  2. This problem be solve if use a newer version fs.promises ( PR #506 )

    • but it is not available in Node.js < 10.



      • NEON supports Node.js-{8, 10, 12} officially



And,

  1. This problem is not critical for neon new...

    • because this problem happens after compled of main work ( the remain works is only show the flavor text )



      • It is no problems if use CTRL+C ( the workaround )




馃 Hmm, I have a little motivation to this issue only the latest environment supports. But I have no interest for older environments and then I don't know the best method that supports the latest and an older versions widely in Node.js. Especially, Node.js and fs looks like jumped between the version 8 and 10, hmm.... I don't know how solve it in practical with no over costs. Maybe, if use sync version APIs... but... hmm... 馃槶

Was this page helpful?
0 / 5 - 0 ratings