We just shipped some library refinements to the Web Build IDE system to make faster iteration possible and accommodate a really important use case folks have been asking for: Forking a library. The particular enhancements are:
- You can delete a private library or published library if no apps include it.
- You can re-import a private library without cutting a new version/release.
- You you can fork a published library, tweak it, and use it privately.
To illustrate how these small features work together, I’ll walk through a couple of use cases:
Forking a library in a nutshell
- I use a library and discover it doesn’t quite do what I want or has a bug.
- I decide to fix it, so I fork it, tweak the code, verify it works as expected, issue a pull request to the original author.
- The original author merges in my pull request and re-publishes the library with the fix.
- Profit. ( in the community sense )
Forking a library in detail
User A has published uber-library-example, and User B wants to add another example to it to illustrate the incredible things they can do with it ( User B knows how to blink an LED with mad styles)
- User B clicks the “fork library” button, forks it on GitHub, clones it locally, adds an example file, commits and pushes it, comes back to the IDE and clicks “contribute library” and punches in the new GitHub URL (i.e. user_b/uber-library-example), then hits import
- User B clicks on the new example they added, and clicks “use this example”, then hits the “flash button” to test out their brilliant creation.
- User B jumps up and down because their example works as expected on the Core.
- User B issues a Pull Request to User A on GitHub.
- User A merges in the Pull Request, edits the
spark.jsonto bump the version (i.e. “0.0.7” to “0.0.8”), commits, and pushes it.
- User A goes to the IDE, clicks “contribute library”, punches in their repo, and hits “import”, then hits “publish”.
- User B deletes their private forked library, and switches back to the published one
…and the crowd goes wild.
Iteratively improving a library
Most of the time when your making refinements or developing a library, you’ll want to develop, check, debug, and repeat until your software behaves as expected. Up until now this process has been cumbersome in the IDE. This is why we’ve introduced the “re-import” process, which simply replaces all of the existing library files you had imported previously with files from the most recent commit. The feature is available for private libraries only, to use:
- Click on the private library you want to re-import files for.
- Make changes in Git, commit, and push them.
- Click the “re-import” button followed by the “import” button.
- Click “Include in App” to use the updated library code in your application or if you already have apps that include this private library, you can simply hit verify or compile on that app again to check that it works correctly.
Next time you want to make a change to an existing library in the IDE, please give these features a shot and please share your experiences and questions here!