We do the same in our project: we bundle all the 3rd party libs when they change, so only our own code gets retranspiled on each page load. During deployment, we bundle all the JS in a single bundle (which is good for us, as we don't have too much JS in that project).
> jspm bundle app//* - [app//*] js/tmp/dependency-bundle.js --inject --no-runtime
That tells JSPM to bundle everything except your application if your app lives within the app/ directory.
> jspm bundle babel js/tmp/bundles/babel.js --inject --skip-source-maps --minify
This tells it to bundle the Babel dependencies which aren't considered in the above.
jspm bundle src/app.js - src/[/*]
This will tell jspm to bundle src/app.js with all its dependencies, excluding everything in the src/ directory. This will result in JSPM bundling only your dependencies.
Also, how long does your actual bundle time take? For small projects, I actually get away with just triggering the bundle command when appropriate files in the project change. I highly doubt it would work for you, but if you're spending 10 seconds waiting for stuff to come in over the network, and your bundle command runs in 5, you could just do that instead, and actually work with the bundled code (and generated source map)
Looks like I'm not the only one who thinks it's sometimes a good idea: https://60devs.com/optimizing--default-jspm-workflow-with-gu...