Guyās, Iām kind of at my limit in terms of patience with the developer experience making plugins. Thereās really two things I try to optimize for when making plugins, those are:
Keeping it efficient
Staying organized
The key downsides of the plugin editor in respect to these goals are it:
Canāt minify or treeshake code for us (without which various plugins would be order of magnitude larger and therefore slower than they could be).
Has a terrible code editing experience.
Only has a versionedlive environment (so keeping track of development versions / experiments in git is impossible).
As a result, the best way Iāve found to make plugins is in a proper code editor like VS Code. But with that, my development flow is:
Make changes to code.
Run esbuild to treeshake, minify, and do whatever other postprocessing to the code.
This produces a bundled a function I have to open up (itās in another file).
I copy this bundled code.
Switch windows to the plugin editor.
Click on the tab for the plugin editor.
Locate the correct action I want to update (if not already in view)
Located the correct actionās code block to update (if not already in view).
paste the code copied from step 4 into the correct code block in the plugin editor.
Switch tabs to the correct bubble app thatās running my plugin (in test mode)
Refresh the page.
Select inputs needed to test my latest code.
If itās an SSA Iām testing, wait 3 to 10 seconds for it finish running.
If the SSA crapped itself (happens 99% of the time), then read the error output.
Repeat steps 1 through 14 until the plugin works.
I AM SO SICK OF THIS
Itās tedious. Too error prone.
easy to paste code into the wrong SSA or visual element section
did I forget to paste the latest local code revision into the plugin before trying to test it?
which of my local git commits is associated with any given published version?.. No clue.
The solution?
Iām not done making pluginsā¦ so am thinking of making a local development flow that eliminates steps 2 through 9. Instead, weād be left with:
Make changes to code.
git commit to the development branch.
Switch windows to browser tab already on bubble app running my plugin (in test mode).
Refresh the page.
Select inputs needed to test my latest code.
If itās an SSA Iām testing, wait 3 to 10 seconds for it finish running.
If the SSA crapped itself (happens 99% of the time), then read the error output.
Switch back to VS Code to make best guess changes to fix the relevant code.
Repeat steps 7 through 8 until the plugin works.
Since this is all just node / javascript, I could even make a hefty chunk of the testing flow a local endeavorā¦ allowing us to specify version controlled testsā¦ meaning most of the time development could look like:
Specify tests
Make changes to code.
git commit to the development branch.
Review local test results
If tests pass, then test in bubble app. Otherwise, repeat steps 2 through 4.
If I can package this development flow into a node module (or VS Code extension), would anyone want it?
Iāve run a few experiments to see if this is technically possible and I believe it is. Making a distributable tool like this would take time so I would charge for it (on a per developer or per plugin basis). But if plugin dev is enough of a pain for you that paying for a better experience is worth it, then please post a comment with your enthusiasm or suggestions. Thanks
Hey @zelus_pudding , I empathize! Iāve been using an external editor and Bubbleās built-in Github integration for years.
Basically, all changes are synchronized through the Github repository that Bubble creates, which is FAR from ideal but worth it to be able to take advantage of source control and external build tools.
Iām still holding out hope that Bubble will create an API which allows external tools to communicate directly with their servers to read/write plug-in files (not unlike Google does for GAS).
So to answer your question, Iāll just continue with my current approach (and maybe start ).
Doesnāt the GitHub integration force plugins to increment their āsubmitted versionā every time you sync GitHub back to the plugin? Is that true or am I just hallucinating that?
Because if thatās true, that makes GitHub sync completely unusable for plugins in production (since those commits are untested).
Plus, the sync is manual. One still has to open the plugin editor, tap the GitHub sync button, then reload the plugin editor. Right?
Woah, I was wrong! It doesnāt auto increment the deployed version. Thatās excellent. But we still do have to manually sync the github version.
I said it was FAR from ideal, but itās still better than using the plugin editor. I do some copy paste at times as well, but I consolidate virtually all my code into the initialize function, so thatās also a streamlining technique.
As I said, ideally, editors like VS Code or JetBrains IDE would be able to read/write files directly to Bubbleās servers. Iām sure thatās totally doable. Itās just a question of whether Bubble has the resources and sufficient incentive. Time will tell I guess.
You know, for whatever reason the github sync always gave me issues the few times I tried itā¦ but isnāt now. Am sketching a much better development flow (one that automates the require manual github sync while isolating local code in a way that can be tested, tree-shaked, and deployed back to bubble). Will follow up / post when I iron it out. Thank you so much for your comments everyone. This convo has really brightened my day.
There were definitely a few kinks to work out early on. I recall sending at least a couple support requests to fix a borked sync back in 2018, but I havenāt had any issues since.
I tried building something like in the past but was not sure if there would be enough interest. I do have a boilerplate I use and VS code Snippets.
If there is enough interest in this and we can truly work on this as an open-source project collectivly I can share the repos. Hopefully from there it can become a true extention
Hi all. Iāve spent the last three weeks building Bask - a VS Code extension for streamlining Bubble plugin development. While Bask itself is not yet prime time ready, I have a first draft of our docs posted here.
Ideally, Iād like to get feedback on this first draft of features / docs.
Given the effort to produce this thing (but more importantly, to maintain it) this would be something I charge for on a monthly / annual basis. That said, this will have features that likely pay for themselves, such as:
Automated and recurring plugin unit test reports and alerts
AI plugin developer assistant
Plugin usage statistics
Those who are interested in being an early user and who provide feedback would get 30% off our product for life (where the price is yet to be determined but will be set to be enticing). Would love to hear any thoughts, recommendations, and respectful criticism. Thank you!
Great work, dude. Thank you for the contribution! This seems really cool. Building plugins has always been a pain in the ass, for sure. Just the lack of a simple āformat codeā ability drives me crazy.
In addition to what Exception and Doug said, VS Code, of course, does a great job of formatting our code once weāve manually git synced it from Bubble to a local workspace. Big goal of this project is to automate all of that manual syncing. That and maintain git-controlled versions of our production files AND source files.
).
What are those second groups of buttons in English? 