4

While working on a number of Aurelia applications we reached the point that we need to share code between these applications.

The code to be shared is not something we (actually our customer) would like to be open sourced. So we were thinking of creating private jspm packages so we can easily reuse our modules when needed. This idea is inspired on this blogpost

Jspm does support linking packages as well so that is something we would really like to use during development, as the code to be reused is not yet stable enough.

Workflow with linked jspm packages

So our intended workflow is to create different number of projects/modules with ES2016 code and create jspm packages from these projects. These packages will then be installed and linked in our applications.

Transpiling

As far as we know jspm packages need to be transpiled before you install it into your project. So we always need to transpile code if there is any change.

According to this systemjs/babel-plugin documentation there will be support for on the fly transpiling in version 0.17 (which is in beta at this point). Currently we're using jspm version 0.16.32 which does not support on the fly transpiling with babel 6.

Somehow this workflow feels over-engineered, so we consider on the fly transpiling in our applications, though we fear a performance penalty.

How would you approach sharing es2016 code between different Aurelia applications?

Is there anyway to achieve code reuse without using jspm packages?

Community
  • 1
  • 1
Andrew
  • 5,395
  • 1
  • 27
  • 47
  • Everything you said makes sense for me. I think that on the fly transpiling could be bad for performance. Yeah, every time you update the module, you'd have to update it in the others projects as well. In either backend or frontend development the workflow is the same. To use a new version, you have to download the new dll/package and pray to not get any breaking changes. Even APIs, which is a link that in theory would never change, you have to specify a version (usually via url or http header). – Fabio Apr 08 '16 at 13:24
  • In short, IMHO what you're trying to achieve is not something easy in these days. Even if you achieve, it could have several side-effects. – Fabio Apr 08 '16 at 13:28
  • **"Yeah, every time you update the module, you'd have to update it in the others projects as well"**: With the use of `gulp bump-release` or something similar in combination with `jspm update` we have versioning. This way we can control the update process in every project and we don't have to pray for breaking changes ;-) At the end of the day we're talking about packages we develop ourselves so breaking changes is the least of our concerns ;-) – Andrew Apr 08 '16 at 13:41

1 Answers1

1

I personally would publish the packages to an internal npm feed of some sort. Set up the internal feed to mirror the public npm feed, then set your .npmrc to point to the private feed. Then just 

jspm install npm:my-private-package
Ashley Grant
  • 10,879
  • 24
  • 36
  • Thought about that too. To mirror the public feed we need to setup our own couch db and I think that is not worth the effort in this case. – Andrew Apr 08 '16 at 21:06
  • 1
    There are several options that don't involve setting up a couch db instance. Simplest, and quite usable if you're a small org, is to use sinopia. The other options generally involve using a service such as http://www.myget.org/ or the private modules option from https://www.npmjs.com/private-modules – Ashley Grant Apr 09 '16 at 10:24
  • Sinopia looks interesting, tnx for sharing @AshleyGrant – Andrew Apr 09 '16 at 20:13