I appreciate the interest! That said, I reviewed your post from Oct’22 and I imagine this plugin would adequately resolve the pains listed in points:
- 2: Minification breaks on Bubble’s function definitions (because they’re wonky). I have a working system using ES Build that ingests an SSA and minifies / treeshakes without issue. I’m 99% sure my process extends to other minification tools.
-
5: No easy way to save a version of a plugin without publishing it: we version control the entirety of a plugin’s
srcanddistfiles… so any git-commit is one you could revert to. These snapshots can be distributed across themain,bask_dev, and somebask_maintype of branching setup.
That said, what pain points would a VS Code extension ideally solve for you? One I hadn’t planned but could consider is your point 4 - implement an easy Copy / Paste for setting up new Client Side Actions. Are there other pain points you have?
@AliFarahat had mentioned a few of his own pain points in that thread.
- 3: Can’t create / return custom objects! This is solvable. Although I can’t fix the fact it would pollute the Bubble Workspace Dropdown picker with useless API calls, I could create a little VS Code based wizard that correctly implements the hack that makes returning custom objects from SSAs an easier thing to setup.
- 5: Aside from the complaint that the version of Node that SSAs run is out of date (Bubble is fixing that) we will still be unable to use ES Modules. While that is true in one sense, there’s a fix for that. In fact, Scious Search uses ES Modules. The trick is in bundling / treeshaking our code into a production ready version. Bask will natively be able to do this at launch.
- 7: can we have a VS Code extension? I say yes.
If I didn’t address a point you’ve written about, it’s because we can’t solve it with Bask. But I’m curious if I’m missing any others.