Embed Node.js Runtime

[angelozerr]

Provide embed node.js runtime like I have done for typescript.java. It will give the capability to consumes LSP without installing node.js (VSCode does like this I think).

If you are interested, I could do a PR.

[mickaelistria]

How likely it is that a frontend developer doesn't have nodejs installed? I don't think it's worth the effort.

…

-- Mickael Istria Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/> developer, at Red Hat Developers <https://developers.redhat.com/> community

[angelozerr]

If you are developping JEE Application and you wish to benefit with HTML, CSS features you don't need node.js. IMHO, I think Bluesky should work without any other program installation like node.js. VSCode works like this I think.

[mickaelistria]

There are package managers such as rpm for that. I don't think the burden should be carried by BlueSky, especially as it would drastically grow the download size and may lead users to inconsistencies ("why don't Eclipse and command-line behave the same...? [3 hours later] Ok, it's not using the same node.js!").
A simple warning pop-up if node.js is not available or version is too old should be enough.

[angelozerr]

There are package managers such as rpm for that.

Take a sample. I have a computer where node.js is not installed and I want to develop HTML, CSS, JavaScript application:

• I install VSCode, it works.
• I install Eclipse IDE + BlueSky, it doesn't work. I don't need node.js, so I telll me why I must install node.js. I give up BlueSky and uses VSCode.

None offense with your idea, I would like just to give you some feedback with typescript.java where user like the embed node.js feature.

it would drastically grow the download size

The update site provides (like typescript.java) an optional installation of the embed node.js

[mickaelistria]

Ok, so it could simply be a change in https://github.com/mickaelistria/eclipse-bluesky/blob/master/org.eclipse.bluesky/src/org/eclipse/bluesky/InitializeLaunchConfigurations.java#L56 to use alternative strategies:

• If node is in PATH, use it (current)
• If not and node is found in the Eclipse IDE installation (we could/should consume the node.js runtime packaged into some Eclipse plugin.

Doesn't JSDT already provided an embedded node.js that we could reuse (instead of writing yet-another-bundle including nodejs?) - cc @ibuziuk
Or maybe we could simply reuse the bundle that's in typescript.java

[ibuziuk]

Doesn't JSDT already provided an embedded node.js that we could reuse

Unfortunately, no. We wanted to bundle node.js with JSDT and opened CQ[1] (which has been approved for a couple of month by now) but literally had no bandwidth to implement it.

[1] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=11306

[angelozerr]

@ibuziuk thanks for your answer. Your CQ link is good?

I think it should be very cool to have an official embedjs nodejs runtime which could be consumed by tern.java, typescript.java an lsp4e/bluesky.

[ibuziuk]

@angelozerr good catch. I have updated CQ[1] link - node.js Version: 4.4.3

[1] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=11306

[angelozerr]

Thanks @ibuziuk

current node.js is v6.11.2 . I don't remember but I think I had some trouble with tssererver/protractor or tern.java with this version. IMHO I think we should consume v6.11.2

[ibuziuk]

@angelozerr than new CQ should be created and one for 4.4.3 should be used as a piggyback

[jabby]

I have a little question : is node.js runtime embedded in other IDE like Netbeans and Intellij IDEA ?
I don't think that embed node.js runtime is a killer feature. A good warning should be sufficient.

[PhaserEditor2D]

I think that there are many Eclipse projects right now using nodejs, maybe the better is to create a third project, something like the NodeRT for Eclipse project, that is just about to bundle the node runtime so it creates consistency across the different projects that require this runtime.

Then the end users can install node into eclipse optionally, and the node runtime can be updated via eclipse updates, or different versions of the runtime can be installed at the same time and the projects can use the one they need.

[mickaelistria]

@boniatillo-com That is a good idea and it was already wished/discussed in the past without much action emerging from it. You could bring this to the appropriate Eclipse.org mailing-list and lead this initiative.

[JoyeLuo]

I was wondering that is it possible that we can use it without node.js?
Like write some code to run it by the tool itself?

[mickaelistria]

All language servers internally used by BlueSky to compute completion, hover and so on do require node.js. So node.js is a strong requirement for complete feature set.
If you're interested to contribute inclusion and shipping of node.js inside BlueSky to remove the dependency, that'd be welcome.

[paulvi]

That was @angelozerr initial proposal to do PR if there is interest,

[mickaelistria]

See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=542488 where CDT folks also consider shipping a node.js runtime.

[PhaserEditor2D]

And VSCode is not required too?

[mickaelistria]

And VSCode is not required too?

Nope, VSCode is not required, its interesting parts are embedded in the jars at build time.

[PhaserEditor2D]

I think a quick solution about node is to do similar to JRE. The user (or product developers) can place node in a node folder next to the eclipse executable.

[PhaserEditor2D]

Another simple solution is first to try with a system property, something like

-Dorg.eclipse.wildwebdeveloper.nodepath=/path/to/node

[PhaserEditor2D]

Users can change it in the eclipse.ini and plugin developers can change it at runtime.

[mickaelistria]

Users can change it in the eclipse.ini and plugin developers can change it at runtime.

A preference should be preferred for that.

In any case, independently of the packaging we target in fine, the method InitializeLaunchConfigurations.getNodeJSLocation() could be augmented to support more heuristic like

• reading a preference,
• reading a system property
• look inside a specific folder relative to the launcher
• ....

There is no.restriction on what conventionq we could support, as long as they seem reusable by multiple clients, so feel free to submit PRs.

[mickaelistria]

Can Eclipse project just re-use existing third-party binary?

Yes, I think so. but as node.js will be included in some feature or bundle, it will be signed anyway.
We typically do that for all language servers.

[akurtakov]

Mickael, should this be in wildweb or in some other project? EPP? I ask as a shellwax maintainer and shipping correct nodejs version could be of interest there too?

[akurtakov]

@mbooth101 Mat, how would this affect flatpaks? Please raise your concerns and requirements so it's not done in a way making shipping as flatpaks harder.

[mickaelistria]

IMO, as I don't see immediate gain in using another project, let's start with Wild Web Developer, and make it a dedicated feature that can be used by others.
Then, if later we feel it'd be better to extract it into a separate project, we'll do it.

[mbooth101]

@mbooth101 Mat, how would this affect flatpaks? Please raise your concerns and requirements so it's not done in a way making shipping as flatpaks harder.

Hmm, I'm not too concerned. In flatpak we only ship the nodejs executable for the user's running architecture. Will this be shipping fragments for all the architectures that Eclipse supports?

[akurtakov]

@mbooth101 Mat, how would this affect flatpaks? Please raise your concerns and requirements so it's not done in a way making shipping as flatpaks harder.

Hmm, I'm not too concerned. In flatpak we only ship the nodejs executable for the user's running architecture. Will this be shipping fragments for all the architectures that Eclipse supports?

Fragments for all archs will be available but only the current one being installed via proper filters.

[mickaelistria]

I've started some work about it on https://github.com/mickaelistria/wildwebdeveloper/tree/nodejs . Currently, it's only showing some structure for fragments and hacking a bit the resolution of node.js location accordingly.

[akurtakov]

@vrubezhny ^^

[AObuchow]

When this bug is resolved, it might be useful to allow Node to be invokable by an extension point or something similar. This would allow Eclipse project builders to be created which run JS or an npm script during auto builds. For example, being able to run Prettier from the project's node_modules directory on project save.

[nitind]

What happens now on platforms where the embedded node isn't available, like ppc64le?

[mickaelistria]

What happens now on platforms where the embedded node isn't available, like ppc64le?

The noxe manager will identify node isn't embedded and will then try to find node in PATH, just like it used to happen for other platforms before node embedder.

[nitind]

Maybe I've got this backwards, but is WWD supposed to require the embedder?

[mickaelistria]

IIRC, it's an optional greedy requirement, so it gets installed by default, and then users can uninstall it.
But it's a bit messy from user perspective, https://bugs.eclipse.org/bugs/show_bug.cgi?id=562679 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=562678 would need some love to better cover this story.