Thank God I use the least amount of plugins as possible. The ecosystem needs a serious reboot…
I made a similar suggestion above, but they did not respond
that’s why we make our own 
HI Grace,
I had a chance to test the latest NPM of PDFJSDist on AWS Lambda using Node16. The package fails to run in this environment because of a broken libz dependency in the Canvas NPM. I believe at least the PDFJSDist failure is because of a mismatch between the default libraries in the AWS Linux environment and the libraries that the latest version of PDFJSDist have been built against.
I’m still investigating why the AWS SDK has to be pinned at an older version.
You raise a valid point. I would guess that a number of plugins will need to be updated as a result of this change. Maybe Bubble should require that all plugins be version updated (from a certain date) which would eliminate any broken/unmaintained plugins from the ecosystem (just a thought).
If I am not mistaken, the Apple app store and Google Play Store have details about when the last update was published, for what version of ios / android it was developed for and more. I think that breaking changes in any closed ecosystem is to be expected (no matter how hard they try not to).
However, I feel it is in everyone’s interest for there to be more transparency about those details on plugin pages. Less tickets for support to handle and less time wasted by Bubble developers. For example, if I see a plugin that was last updated three years ago and that it is running on version 1 of the plugin API I am really unlikely to install it.
I think we need to be louder about this. We need transparency!
Bubble and transparency unfortunately aren’t synonyms. If they were, Bubble would be 2x the size!
Hi @grace.hong : is there any update on the Node 16 upgrade availability? We’re building some plugins now that require Node 16 and I don’t want to promise anything to customers if this is not happening any time soon. I know EOL on Node 16 is just a couple months away (30 Apr 2023 to be exact). Also, is there any way a specific plugin can be given early access (if Node 16 is something you already have available)?
Josh said this in the community update yesterday:
Hi @nicholasrbarrow, I’m the PM leading the Plugin Node 16 upgrade project now (taking over from Grace)—we are aiming to ship an option to upgrade plugins Node 16 in April. Unfortunately we can’t give early access to any specific plugins.
@henry.dowling This is great to hear, thanks for leading this important project.
Do you expect to EOL plugins that do not upgrade to Node 16 within a certain time window?
@henry.dowling thanks for the info! Appreciate the transparency on this.
If you end up being able to give node 16 to specific plugins and need beta testers, I’m happy to help out!
Of course, and I’ll send you a message about beta testing. No pressure of course, but would love to have your input!
Yep, we are going to EOL plugins that don’t upgrade to Node 16 at some point this year. The latest that this could be is November, because that is when AWS will stop letting us run server-side plugin actions on their servers. However, we might decide to officially EOL plugins that don’t upgrade to Node 16 earlier than that in order to give Bubble users whose apps use affected plugins time to ensure that they don’t lose any functionality. I will make an official announcement about this whole process in the coming weeks!
Awesome! We will be waiting for it 
Can you elaborate @nicholasrbarrow? I assume you are talking about ESM?
@redvivi there’s some libraries that we want to use that were Node 16+ (I think it had to do with the libraries using Node-features that weren’t released until Node 16).