I'll remove node-red-contrib-flow-statistics at the end of the year.
Please, use the dsm node instead:
https://github.com/cflurin/node-red-contrib-dsm/wiki/Statistic
I hope so to help reducing the amount (approx. 1760) of contrib-nodes.
Would it possibly make more sense to add messaging on the node's planned deprecation on github/npm and possibly do a final update that throws an occasional warning message advising users to migrate their flows? I understand the desire to do housekeeping, but outright doing away with the contrib node could cause issues with flow imports and migrations of existing projects.
Thanks for your hint.
My intention is to just remove it from the node-red library.
I think I have to delete the keyword node-red in the package.json
"keywords": [
"node-red",
I don't plan to delete the GitHub/npm repository.
But I'll add a warning message anyway to the README.
Hey Flurin,
We had a similar issue some time ago, with the red-contrib-image-output node that had to be replaced by the node-red-contrib-image-output module. I think the author used this to mark the npm package as deprecated.
Thanks,
First I'll remove it from the node-red library (at the end of the year).
If/when you use the npm deprecate command - make sure you include all versions of your node or user may accidentally install any that are left un-touched.
I see the need to control the number of contributed nodes (and the burden of maintaining them), but I think there is some risk of making it more difficult for users to find what they need.
In this case, I would suggest two things. First, include the wiki example Statistic in the GitHub /examples directory so that it appears in the user's Import:Examples menu. (I realize this example is just one among many, but I think it is as important as some of those already there.) Second, consider re-naming the example as Flow Statistics so that its function and relationship to the deleted node-red-contrib-flow-statistics is clear.
How the user will figure out that the way to count and classify the nodes in his flow is to download node-red-contrib-dsm is a different question.
Good to know! Let's see whether I need to do it.
- That's easy, I'll add it to the examples in the next version.
- I've already used this name for several links but I'll change it by the next update.
In this case less is more 
. I've removed the npm installing instruction in all my README since node-red added the menu Manage palette.
Installing contrib-nodes is nowadays a node-red basic instruction. And who knows, maybe node-red will be able to install missing contrib-nodes automatically in the future.
Actually in this case less could be less - What is someone wants to install via NPM? I always go and look at the readme just in case there is a dependency that I have to manually install.
I wish the 'Manage palette' would be setup so when you pressed install, it would display the ReadMe and at the bottom of that a continue/exit button - although people would still blindly press continue without reading the ReadMe anyways 
Good point! well in the case a node can't be installed using the Manage palette then obviously additional instructions are mandatory in the README.
BTW the npm install instruction is added by npm automatically and is also visible in the node-red library.
What happens if npm improves the install instruction or modifies it? Then all the READMEs must be updated.
So the less is more concept maybe a good approach.
My real intention here was to point out that node-red-contrib-dsm can be programmed to do virtually anything. (A finite state machine is practically, if not theoretically, a general-purpose computer.) So if a dsm is written for a common task (like counting nodes), there should be a way to inform users of that. If some of the example flows were published to the library with descriptive names, it would help make them discoverable, at the cost of increasing the size of the library again.
@drmibell,
Good point: I agree for a new user it isn't easy to search for an example.
From the point view of a developer (maintainer) the best is to keep the examples in a repository and use a link to them.
Jus now I use a computer (mac) for development, a RPi 3B+ for testing, the github repository including the examples folder and the wiki and the npm registry server.
That means if I have to fix/modify an example, it would take several steps to update all them.
The examples folder in the node source is great for the user but by a new example version I have to publish a new node version, therefore I prefer to keep the examples in the github wiki.
If you think the flow-statistics is useful, please add a flow to the node-red library using this link. You can also add an introduction/description to the wiki.
