Closed Chris2011 closed 7 years ago
There are still some differences that make it worth keeping around. I think the folks who did support for Node at Oracle got some things fundamentally wrong:
nbproject/
directory, rather than doing the right thing and using or extending package.json
for its metadataIn short, NetBeans built-in support for NodeJS is really more like "support for projects with a package.json file" - it's NPM support, with NodeJS as an afterthought. For writing actual code to run in NodeJS, it still leaves a lot to be desired.
By all means, use whichever works better for you.
The thing is package.json will always used to detect a HTML5 project than you can add NodeJS support to it, if you want it. So that means, that you can have a FullStack applicaton with a backend and with a frontend. As I understand it right, with your plugin, it will always be a full backend without having client to run, right? The other hand, how will you treat a package.json as for a node application with your plugin, and for a HTML5 Project in NetBeans? It is the same package.json file. Maybe you can add a new property to it that this should work.
The problem for me is, why we need two different plugin, which makes similar things? I would prefer to only have one which is highly customizable and work in each way. So why not extending the exsting code of the NetBeans core for Node? What you said, maybe you can rewrite it or extends it.
I know the problem that you can't run each js file in a HTML5 project, when you don't add node,js to it and you are inside a sources folder. I created a ticket for that.
Think about, maybe it could be merged together. I will try your plugin too soon. Thx for the info.
Yeah, the fact that web frameworks adopted npm
wholesale - same package.json
file name is the problem (not a problem I created, but it has turned npm into a slush-bin of random crap).
I would love a way to differentiate actual Node projects from impersonators, but there are several problems with that:
The code that identifies which plugin owns a project runs inside the paint loop in a file chooser - it has to be fast and should not do any file reads (if you're scanning a folder with a thousand subfolders, you're not going to read several thousand JSON files and classify them in the 200ms you have before the user perceives something is slow - and this code will run any time the Open Project dialog is open. In-depth inspection of folder contents is not an option).
There is no reliable way to do that that doesn't boil down to guessing - say, looking at the libraries used or scanning sources and deciding something rules it in or out, and there will always be cases where that gives the wrong result
Inventing a property to put in package.json
is a non-starter, because the whole point is to be able to open and use a project someone else wrote that you just, say, cloned from Github. There is no way to dictate to every Node project on the planet that they need to go add properties to their project to mark it as a Node project just for the convenience of me and NetBeans users. And dropping turds into someone else's package.json
is bad behavior for a thousand reasons, starting with the fact that now you don't have a clean checkout anymore but you didn't intend to alter it or know you did. Opening a project in an IDE should not screw around with the project's data, under any circumstances, unless you want nobody to use that IDE.
Note that there is a menu action on Node projects managed by this plugin Mark as not a Node project which will disable this module for that project.
Don't get me wrong, I'd love to deprecate this plugin, or turn it into a set of services that plug into the other. At the same time, this plugin pre-dates built-in support in NetBeans by several years, and was intentionally licensed such that the NetBeans team could grab any of it they wanted (bear in mind, I am one of the original authors of NetBeans and worked on it at Sun for 11 years). It doesn't appear that they even looked, or got to know what Node project authoring is actually like - it's just a thing bolted onto web projects. And what's there seems to be designed to make integrating with it extra-excruciating - I've taken a pass or two at improving syntax highlighting support (completion for built-in Node modules, provide the under-the-hood self-executing wrapper function Node wraps module js in, so things that aren't errors don't get marked as errors, stuff like that), but unless I have a month of my life to devote to it, it's not going to come from me.
So, in short, sorry there are two plugins. This one does offer a way to gracefully get out of the way where it's not needed. If you're primarily writing server-side Node code, this is the one you want. If you're doing something else, it probably isn't.
What does this plugin for node developers what we not have in the official supported implementation from Oracle inside NetBeans? If there is some, maybe it would be good that you can contribute to the original one? Or is this plugin obsoleted?
Regards
Chris