Don't copy all bower_components in build process

[chuckh]

Currently the polymer build process copies all bower_components files to build/bundled even though most are vulcanized. For PSK2 this lengthens the build process on my MacBook Pro Retina to 58 seconds from 18 seconds.

In PSK1 we do the following:

// Copy all files at the root level (app)
gulp.task('copy', function() {
  var app = gulp.src([
    'app/*',
    '!app/test',
    '!app/elements',
    '!app/bower_components',
    '!app/cache-config.json',
    '!**/.DS_Store'
  ], {
    dot: true
  }).pipe(gulp.dest(dist()));

  // Copy over only the bower_components we need
  // These are things which cannot be vulcanized
  var bower = gulp.src([
    'app/bower_components/{webcomponentsjs,platinum-sw,sw-toolbox,promise-polyfill}/**/*'
  ]).pipe(gulp.dest(dist('bower_components')));

  return merge(app, bower)
    .pipe($.size({
      title: 'copy'
    }));
});

[chuckh]

Also when using this above approach to build and then deploying PSK 2 to Firebase the process went from 3 minutes and 58 seconds to 57 seconds. Firebase deploy went from copying 2700 files to 126 files.

[antonmoiseev]

For firebase deploy we use "ignore" property in firebase.json file.
https://firebase.google.com/docs/hosting/deploying#ignore
On Jun 7, 2016 3:10 AM, "Chuck Horton" notifications@github.com wrote:

Also when using this above approach to build and then deploying PSK 2 to
Firebase the process went from 3 minutes and 58 seconds to 57 seconds.
Firebase deploy went from copying 2700 files to 126 files.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Polymer/polymer-cli/issues/241#issuecomment-224126018,
or mute the thread
https://github.com/notifications/unsubscribe/AALKRZ-ndwcguKJugUn4UyGiBu9q-ZKxks5qJLb6gaJpZM4IuWxu
.

[addyosmani]

I think in reality, we're going to have users who deploy to different possible end-points with Firebase being just one (PSK1 was most often deployed to GAE). It would be great to come up with a generic approach to this (like we had in PSK1) that avoids having to deploy thousands of files.

[chuckh]

@antonmoiseev thanks for pointing that out. The only problem with using ignore for bower_components is that you don't want to ignore the entire directory you need to do it selectively, not webcomponentsjs,platinum-sw,sw-toolbox,and promise-polyfill but all other components. So it makes for a very long ignore section. Also it does not address the issue for other platforms such as GAE, and GitHub pages.

[antonmoiseev]

@chuckh definitely agree, we need a generic mechanism for filtering out build assets. Just noticed you mentioned Firebase and since we had the same issue, I shared the solution that works quite well for us. In our case ignore list is not really long ~10 lines. We exclude the entire bower_components directory, but explicitly negate the files we want to be included. Take a look at webcomponents-lite.min.js:

"ignore": [
      "bower_components/**",
      "!bower_components/webcomponentsjs/webcomponents-lite.min.js",
      "test/**",
      "bower.json",
      "firebase.*",
      "package.json",
      "polymer.json",
      "README.md"
]

[chuckh]

@antonmoiseev thanks for sharing the ignore approach!

I created this firebase.json based on your example for PSK2 deploying to Firebase.

{
  "database": {
    "rules": "database.rules.json"
  },
  "hosting": {
    "public": "build/bundled",
    "ignore": [
      "bower_components/**",
      "!bower_components/webcomponentsjs/webcomponents-lite.min.js",
      "!bower_components/marked-element",
      "!bower_components/platinum-sw",
      "!bower_components/promise-polyfill",
      "!bower_components/sw-toolbox",
      "test/**",
      "bower.json",
      "firebase.*",
      "package.json",
      "polymer.json",
      "README.md"
    ],
    "rewrites": [
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}

[justinfagnani]

Just to clarify why we include all of bower_components in the build output: In general there's no way of knowing what dependencies will be needed at runtime - that's completely dependent on application code, and so the most conservative and safe thing to do is write all of the files.

We can add an option to filter files after the bundling step.

[FredKSchott]

Closed by #310