Native node modules from extensions #658
Comments
|
I'm doing some more investigation on this to see if I can unblock myself by getting an Now I get the following error:
Are native modules not supported in extensions? |
|
The good: Nothing really.
|
|
Yeah I just came across this walkthrough which somewhat outlines the "ugly" side of things 😛. Native modules are a pain, but I might keep at it and see where I can get to (or see if the native module can be reimplemented in "plain ol' JavaScript", but somehow I don't expect it to be possible. |
|
We use the npm way in our build scripts, btw. |
|
I've been playing around with the easy way and got this far:
So - I now have a "working" native node package running in a VSCode extension. But I was curious as to why it wanted a folder of Anyway I can at least get the extension launched, so chalk that up to success number 1 😁. |
|
I've hit another problem that I'm not sure if it's related to it being a native module or if it's another bug, the native module is being reported as not found by VSCode's editor and the TypeScript compiler (when running the If I run from the debugger it works just fine, the native module is loaded, executed, etc, so I know it's there, but |
|
It seems that you just need TypeScript typings to go along your native module. Try placing a file in your extension similar to this:
declare module 'mylib' {
export function foo(arg: number): void;
}Then, both VSCode and TypeScript would drop the errors when you'd import the module: import * as mylib from 'mylib'; |
|
ah, I didn't realise you need to have everything with a Is there any way (easy or ugly) to work out the version of Electron when installing a plugin? |
|
You must always compile it against the version of Electron that VSCode depends on, considering the VSCode version you're targeting. So, for VSCode 0.10.3 it is Electron 0.34.1. |
|
Yeah I found that out, I'm just trying to avoid shipping a precompiled version of |
|
Very tricky and it's exactly the reason why we haven't tackled this yet: every user that would install your extension would need the build tooling installed in their system (VS, gcc, etc.). |
|
Yeah that's a fair point, I guess shipping the compiled module in my extension is probably a good idea (or at least the binary) and get it done for each platform. I might be able to make an assumption of the build tools (given that it's work working with microprocessors) but it's solid assumption. |
|
Is there a mechanism for downloading precompiled binaries as part of the build process, such that extension creators could use a tool to pre-compile an array binaries for different platform and node version targets - and the build process would bring down the appropriate binary and link it? |
|
node-pre-gyp exists for that purpose when dealing with node modules. But upon installation, we don't call |
|
So Atom's apm 1.10 beta seems to ship with node and npm now, likely to avoid these exact issues http://blog.atom.io/2016/08/01/atom-1-9-and-1-10-beta.html |
|
Yep... it's starting to feel inevitable by now. |
|
I haven't done much with this for a while but my current thinking is that instead of trying to load the native module within the electron shell I think it'll be better to use I'm thinking this because it seems that the |
|
Is there anyway to see the error messages upon faulty loading? I am trying to make a language server that makes use of a native module. I've followed the steps outlined here and here and have arrived at a module that can be loaded from the extension. So far so good. However, when my extension starts the server that tries to reference the same native module I get "The Swift server crashed 5 times in the last 3 minutes. The server will not be restarted." This does not exactly give me a lot to go on to try and resolve where it is going wrong. And the process is dead before I have a chance to attach a debugger to it. If I could just get some messaging about what/why the server is dying that may help me crack the case. |
|
@RLovelett the problem is now that the version of Electron used in VSCode is a bit out of date (0.37.6 in the insider build of This is why, for me, I'm thinking of running |
|
I am also dealing with this issue, and there is one thing I do not quite understand why: wouldn't it be easy and perfectly acceptable for vscode to just rebuild all extensions while installing using just as recommended in https://github.com/electron/electron/blob/master/docs/tutorial/using-native-node-modules.md, as this command would do nothing for packages without native node modules, and fix all the issues with the others? I believe it is natural to expect for vscode to fix the node dependency issues since it does not provide access for electron's node to the extension developers, so it should act as a black box. |
|
hi moderators, I could rebuild locally and test out my extension. But if I pack and publish it, it doesn't work in the client's machine. Please do let me know if you guys have any solution for publishing. Thanks! |
|
@ganezdragon for what it's worth, I ask my users to go to the extension folder ( |
|
@pythoulon thanks for the approach. Yea then I would have to go with this, and hope the users have necessary gcc also to compile it. Or I would have to look at some web bindings (but that has its problem of its own). |
|
@ganezdragon @pythoulon - Have either of you tried prebuilding your native node module with prebuildify and then including the binaries in the published npm package? You can use this approach to avoid making your users run |
|
@bmealhouse, nope I haven't tried it. Let me try it out today and see how that works! Much thanks for telling us about the library. |
|
@bmealhouse Will try it as soon as I get a chance. @ganezdragon please report here on your experience, if you can... Thanks. |
|
@bmealhouse Finally got a chance to take a look at prebuildify. The problem I have is that my extension module is not native per se, but it depends on a couple of native modules. I'm not sure how to use prebuildify in that context. Ideally I would like to deliver my module with the prebuilt versions of those modules (which, as far as I understand, do not come with prebuilt binaries). |
|
@pythoulon - You could fork those native modules and prebuildify them for VS code. |
|
@bmealhouse Thanks for the hint. Hadn't thought of it... Will try that. |
|
I'm running into this issue currently. In particular, I'm trying to use nodegit which has a native dependency on libgit2. At first I was seeing some But now I'm seeing an error: Is there a plan for a more robust native dependency solution for VSCode extensions? |
|
I need help implementing this in a sane manner over at |
|
I found a solution mostly written by MS devs: 'use strict';
import vscode from 'vscode';
/**
* Returns a node module installed with VSCode, or undefined if it fails.
*/
export default function<T>(id: string): T | null {
try {
return require(`${vscode.env.appRoot}/node_modules.asar/${id}`);
} catch (err) {
// ignore
}
try {
return require(`${vscode.env.appRoot}/node_modules/${id}`);
} catch (err) {
// ignore
}
return null;
} |
node-pty will be used to provider a better interactive terminal. It's required to have colors and progress bars from bitbake. Explanation: microsoft/vscode#155444 (comment) However, VSCode uses electron which has it's own npm NODE_MODULE_VERSION. I had to use `@electron/rebuild` to match the version. I wonder if it would break when VSCode updates electron. There are discussions which failed to provide other workarounds (we don't use webpack yet): - microsoft/node-pty#582 - microsoft/vscode#658 The format of the files and package-lock.json where updated by npm install.
node-pty will be used to provider a better interactive terminal. It's required to have colors and progress bars from bitbake. Explanation: microsoft/vscode#155444 (comment) However, VSCode uses electron which has it's own npm NODE_MODULE_VERSION. I had to use `@electron/rebuild` to match the version. I wonder if it would break when VSCode updates electron. There are discussions which failed to provide other workarounds (we don't use webpack yet): - microsoft/node-pty#582 - microsoft/vscode#658 The format of the files and package-lock.json where updated by npm install.
VSCode and the Jest native environment use conflicting NODE_MODULE_VERSION. We have to use node-pty from VSCode when running in the VSCode environment and the regular node-pty when running in Jest. Following the idea presented in: microsoft/vscode#658 (comment) We use dynamic imports to load the correct node-pty. The types must still be imported normally at compile time.
node-pty will be used to provider a better interactive terminal. It's required to have colors and progress bars from bitbake. Explanation: microsoft/vscode#155444 (comment) However, VSCode uses electron which has it's own npm NODE_MODULE_VERSION. I had to use `@electron/rebuild` to match the version. I wonder if it would break when VSCode updates electron. There are discussions which failed to provide other workarounds (we don't use webpack yet): - microsoft/node-pty#582 - microsoft/vscode#658 The format of the files and package-lock.json where updated by npm install.
VSCode and the Jest native environment use conflicting NODE_MODULE_VERSION. We have to use node-pty from VSCode when running in the VSCode environment and the regular node-pty when running in Jest. Following the idea presented in: microsoft/vscode#658 (comment) We use dynamic imports to load the correct node-pty. The types must still be imported normally at compile time.
node-pty will be used to provider a better interactive terminal. It's required to have colors and progress bars from bitbake. Explanation: microsoft/vscode#155444 (comment) However, VSCode uses electron which has it's own npm NODE_MODULE_VERSION. I had to use `@electron/rebuild` to match the version. I wonder if it would break when VSCode updates electron. There are discussions which failed to provide other workarounds (we don't use webpack yet): - microsoft/node-pty#582 - microsoft/vscode#658 The format of the files and package-lock.json where updated by npm install.
VSCode and the Jest native environment use conflicting NODE_MODULE_VERSION. We have to use node-pty from VSCode when running in the VSCode environment and the regular node-pty when running in Jest. Following the idea presented in: microsoft/vscode#658 (comment) We use dynamic imports to load the correct node-pty. The types must still be imported normally at compile time.
node-pty will be used to provider a better interactive terminal. It's required to have colors and progress bars from bitbake. Explanation: microsoft/vscode#155444 (comment) However, VSCode uses electron which has it's own npm NODE_MODULE_VERSION. I had to use `@electron/rebuild` to match the version. I wonder if it would break when VSCode updates electron. There are discussions which failed to provide other workarounds (we don't use webpack yet): - microsoft/node-pty#582 - microsoft/vscode#658 The format of the files and package-lock.json where updated by npm install.
VSCode and the Jest native environment use conflicting NODE_MODULE_VERSION. We have to use node-pty from VSCode when running in the VSCode environment and the regular node-pty when running in Jest. Following the idea presented in: microsoft/vscode#658 (comment) We use dynamic imports to load the correct node-pty. The types must still be imported normally at compile time.
and others
I’m looking to build an extension but one of the packages I need to depend on is a native module. When I do an
npm installit installs the package just fine, I can launch a node shell and interact with it, etc. But when I go to use the package from within my plugin I get an error as it’s trying to load the ia32 build of the native module not the x64 which was compiled by node-gyp.A quick bit of debugging indicates that the problem stems by
process.archreturningia32when running in VS Code when my machine is a x64 machine (Win10 x64).So is there some way to either:
Otherwise I fear that my extension might be dead in the water 😦
The text was updated successfully, but these errors were encountered: