Building the bundles for production

270 views
Skip to first unread message

josh...@gmail.com

unread,
Dec 16, 2015, 1:45:52 PM12/16/15
to SystemJS
I'm having a hard time to understand what is the best way to use SystemJS in production, without a HTTP2 server.

I have a complex SPA web app with multiple views (pages) which have multiple child components. Idea is to create a bundle per top-level view and one common js file.

The working setup I currently have looks like this:

- Use ES6 modules and other stuff
- Use SystemJS Builder to construct a trace for all top-level views and the main.js file (which bootstraps the app)
- Intersect the trees, with a custom function, to construct a common tree and using the SystemJS bundle function write it to a common.js file (intersect function from the SystemJS Builder API only works for two trees)
- Subtract a common tree from each of the views trees and write the bundle to a file (products.js, profile.js, dashboard.js, etc)
- index.html is like this:

<script src="/js/libs/system.js"></script>
<script src="/js/config.js"></script>
<script src="/js/common.js"></script>
<script>System.import("/js/main.js");</script>

- When the user clicks on some top-level view link, I do the following:

System.import("/js/views/" + viewName).then(...);

So it lazy loads the needed js.

And everything works great. But I have a few dilemmas:

- How to avoid loading JS with XHR and use script tag injection?
- Is it possible to use buildStatic function in this case, to build a bundle per page (view) and common one and lazy load them when needed? Also in this case, will each of the bundles contain a micro-loader implementation and a Traceur/Babel runtime?

Guy Bedford

unread,
Dec 16, 2015, 4:10:33 PM12/16/15
to josh...@gmail.com, SystemJS
Your workflow sounds good.

You can use metadata to tell SystemJS to load your bundles as scripts:

```javascript
System.config({
  meta: {
    'path/to/bundles/*.js': {  scriptLoad: true }
  }
});
```

buildStatic is not advisable for your use case, as it makes it harder to share dependencies between lazy loaded pages so you end up with duplication.

The only way to take advantage of buildStatic is to explicitly exclude the common code though, so you know the static bundle doesn't need to share its internals:

buildStatic('page.js - common.js', { format: 'amd' });

A static AMD build with a dependency on `common.js` can also be script loaded then.

--
You received this message because you are subscribed to the Google Groups "SystemJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to systemjs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages