Request: Extract chunks as entry

[lukeed]

One of the things I like about Webpack is that I had the able to define an entry as an array of files. Typically these are names of dependencies & not direct file paths.

Then, when importing bits from this array-entry, the useful pieces (after code shaking) are placed in that new, generated file.

This is particularly (and commonly) useful for when there's a single app entry & a declaration of shared vendor scripts. In such case, Splittable AFAIK won't generated a shared _base.js.

module.exports = {
  entry: {
    app: './src/app.js',
    vendor: [
      'vue',
      'vue-router', 
      'firebase/database',
      '...'
    ]
}

// app.js (simple)
import Vue from 'vue'
import Router from 'vue-router'
import 'firebase/database'

Final output should contain all the application script in app.js and all useful chunks within vendor.js.

---

This could probably be achieved already, but it seems pretty silly & I think there'd be some unnecessary code to string together the vendor file to _base:

// app.js
import Vue from 'vue'
import Router from 'vue-router'
import 'firebase/database'
import { item } from 'fake-dep'

// now do custom stuff

// vendor.js
// just redeclare all application imports

import Vue from 'vue'
import Router from 'vue-router'
import 'firebase/database'
import { item } from 'fake-dep'

[cramforce]

I don't completely follow why you'd ever want such a vendor.js file. It seems to make more sense to just have code import whatever dependencies they have and let that bubble up. With a centralized vendor file it is easy to have dependencies in there that nothing in the application actually still uses.

Am I missing something? If you really want a vendor file, why not just for import './vendor' in base.js?

[lukeed]

Because then you'd have a bundle of third party scripts that can be versioned and cached on its own. Same with app.

But now when business logic changes, only a new app file is shipped, as opposed to a massive bundle, the majority of which hasn't changed.

You'd only push down a new vendor when updating a third party script, or adding / removing.

[cramforce]

I see. I personally don't see this as much of a vendor specific problem. Whether they or parts of the app change more often depends on the specific app. The optimizing compiler in splittable needs to see and modify all sources to really do a good job. If that is not a good trade-off you could load vendor files separately and then have a shim module to marshal between them. In practice, with splittable app.js should be tiny (just vendor code + app router), so I don't see much benefit. You could, of course, add a smarter loader that supports independent bundle versioning.

…

On Dec 2, 2016 8:08 AM, "Luke Edwards" ***@***.***> wrote: Because then you'd have a bundle of third party scripts that can be versioned and cached on its own. Same with app. But now when business logic changes, only a new app file is shipped, as opposed to a massive bundle, the majority of which hasn't changed. You'd only push down a new vendor when updating a third party script, or adding / removing. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFeT-Q1x6wJ_ZiBDqV9Zy9ilMBdf2ISks5rEEKZgaJpZM4LCQfm> .