Add default polymer-build configuration

[TimvdLippe]

So, it's a start... You can now run yarn run build (gulpfile taken from https://github.com/PolymerElements/generator-polymer-init-custom-build) and it will correctly generate a jekyll build and then run polymer-build. However, due to my lack of experience with jekyll, urls get hosed and anything other than the homepage completely breaks.

Now there are two options:

1. Full adopt polymer-build and completely remove jekyll.
2. Fix jekyll to generate valid urls that polymer-build understands and then remap nested urls to the correct folder

I am not sure what your preference is @paulirish Personally I would go for option 1, as I am the most experienced with it, but I think this should be your call.

[TimvdLippe]

Oh and the build is generated at _site/build/. So you can serve that directory (for example polymer serve _site/build) and open the url in the browser.

[paulirish]

nice stuff!

option 1 sgtm.
just to confirm, we can't break our current URLs. but i don't think you were indicating that... :)

can we put the squashed assets into a bundledimports.html that each leaf page imports ? that way we get cacheability. I figure its worth it at ~600kb. :)

[paulirish]

@kdzwinel hows this sound to you?

[kdzwinel]

I'm OK with getting rid of jekyll, especially that we think about moving to a SPA ( #80 ). As you mentioned though, we don't want to break URLs, we probably also don't want to move away from GH hosting and make sure that the current protocol.json update process still works. If these requirements are satisfied I'm all for it 👍

[TimvdLippe]

just to confirm, we can't break our current URLs. but i don't think you were indicating that... :)

Oh certainly not! I will make sure they will work properly.

can we put the squashed assets into a bundledimports.html that each leaf page imports ? that way we get cacheability. I figure its worth it at ~600kb. :)

Currently the whole website is unminified, unoptimized, unbundled. So the current config fixes most of these issues. I would propose to first implement the polymer-build and the initial bundle configuration. Then in a new PR we can look into making this side PRPL by splitting up data and installing a service-worker.

and make sure that the current protocol.json update process still works.

I think if we keep the files in the same location (e.g. I only change the way we create the _site) this should still work!

[paulirish]

can we put the squashed assets into a bundledimports.html that each leaf page imports ? that way we get cacheability. I figure its worth it at ~600kb. :)

Currently the whole website is unminified, unoptimized, unbundled. So the current config fixes most of these issues. I would propose to first implement the polymer-build and the initial bundle configuration. Then in a new PR we can look into making this side PRPL by splitting up data and installing a service-worker.

i'd personally defer PRPL for a bit, along with setting up a SW. I was just thinking of creating a new shell html import and setting that as the polymer-build entry point. but then again if that 600kb shrinks to just 30kb after optimizing then no need. :)

[paulirish]

as for sequencing of PRs.... since i automatically push changes from this repo to gh-pages, we'll have to make sure master here is production ready.

you could do the optimized build config in a separate PR which just builds on this polymer-build branch.. i can handle that.

nahmean?

[TimvdLippe]

The current state already optimizes (e.g. minification and bundling). I will open a new PR on this branch for other updates for the jekyll -> Polymer migration. WDYT?

[paulirish]

ah sorry.. when you said "Currently the whole website" i was getting mixed up. thought you meant this PR. :)

yah sg!