First up let me say that Node-RED 1.3.0-beta.1 is coming this week. There is one PR left to merge which should happen tomorrow.
Putting that aside, we're starting to think about the 2.0 release. We published our plan last year that explained how we intend to release Node-RED 2.0 to coincide with the end-of-life of Node.js 10. That happens at the end of April - just 8 weeks from now.
Whilst we aren't looking to make any significant breaking changes (other than no longer supporting Node 8 and 10), releasing a new major version is an opportunity to consider changes that we wouldn't necessarily want to do in minor releases.
We also need to be realistic as to what we can achieve in the relatively short time frame available - keeping in mind that 1.3 still needs to be finished off even after the beta is shipped.
We're putting together a list of the items we want to get done for 2.0. And this is where we'd like to get feedback from the wider community.
The type of thing we're looking at is changing some default node configurations - so existing flows continue working as before, but newly added instances of some nodes may come with a different default setup. There may be some settings in the settings.js file we'll be deprecating in favour of better alternatives.
Are there changes we should be considering? This is not meant to be a feature wish list. It's more about changes to default behaviours, or changing the way something works.
If you are making changes to settings.js, would you consider improving the in-line help information such as I've shown previously? It would make the file a lot easier to read.
If you are switching to the spacetime library - would you consider exposing it to function nodes as well?
Is it time to release some more of the nodes that are installed with Node-RED core? Moving them to their own libraries? The only ones of these I'd ever use is the RBE node. Not sure the Tail node is even cross-platform. I can't imagine that many people make use of the sentiment node.
Apologies if this one seems like it should be on the wishlist, ignore if not appropriate - It would be wonderful if there was a "disable group" feature - at least in the tree view. so that you could disable/enable a grouped set of nodes in the same way you can a flow tab. Doh! just seen that feature in 1.3!
Also just seen the Export Preview feature - could there also be an import preview? At the moment we have to use your Inspect Flow page if we aren't sure whether to import something from the forum.
That sort of improvement could be done at any time - it just needs someone to propose something in a PR otherwise it waits to happen.
Spacetime is one possible alternative. The key is to move away from moment as its heavier than we need and not recommended for new projects. Its the deprecation of moment that warrants the 2.0 alignment. The plan was always to add something to the Function node - but got held back when we realised that moment wasn't the right way to go. So that will happen at some point once we know where we're going.
The 2.0 plan already has the proposal to move RBE into core (rebranded as a more general filter node) - that will deprecate the node-red-node-rbe package. The others are definitely candidates to remove from the default install.
Definitely in the feature request list, rather than a "does it require a major version bump to consider" list... but yes, its on my todo list.
Sounds good -- but I'm interested in what you are considering for a "general filter" to do (besides rbe).
For instance, would it provide payload data filtering something similar to Array.filter(function(d) { return d.cost > 0; }), similar to the sort node?
Or is it intended more for deciding which msg objects to pass along and which to drop?
Currently it’s just a rename so people may find it rather than just miss rbe due to not knowing what that means. Of course it could be extended as well but no plans yet.
I‘m very new to nodered and I have to learn a lot. So maybe this is the wrong thread for me to post, but based on this thread I have a wish from the view of a newbie.
If we have at the template-node already a SQL-syntax highlighting it will be great to expand it with SQL-injection-protection light. For me it‘s the best way to generate complex SQL-queries. In my opinion in many cases it doesn’t matter if it‘s not the fastest on.
I know that it will be not possible to work as described in the solution by request values from the database but it will be possible to look for suspicious values I think.
