PSK2 -> Master checklist

[robdodson]

Future (do once Polymer core is updated to better handle ES6 classes) (PSK version 2.1)

• Migrate PSK2 to ES2015/ES6 (Psk2 polymer build #857)

Done

• Tag a final release of PSK1 (will be v1.4.0)
• Update README (what's in PSK2? How do I use it with CLI? What's different from PSK1?)
• Replace app-drawer-template with PSK2 in Polymer CLI
• Created custom-build template which includes PSK2 and gulp tasks.
  • Migrate PSK2 to a yeoman generator possibly in a new repository, see Polymer/polymer-cli#templates-and-generators
• Update PSK1 README
• Test stub
• Remove docs directory
• Remove auto deploy to gh-pages/firebase (chuck will do these manually to start)
• Remove gulpfile.js (had been already removed in PSK2)
• Add polymer.json
• Move test folder to root (also images and data should be at the root level)
• Add PSK favicon and icons similar too: Update to consistent index.html and manifest.json googlearchive/app-drawer-template#13
• Update minimum Node version to >=4.0 (Update minimum Node version (like polymer-cli) #867)

[chuckh]

Do we want to remove custom elements from their own directories and just put them in /src like https://github.com/Polymer/app-drawer-template/tree/master/src?

Do we want to create a polymer.json file like https://github.com/Polymer/app-drawer-template/blob/master/polymer.json?

[robdodson]

I like the idea of a polymer.json

[abdonrd]

Me too!

[NicolasRannou]

Do you plan to add es2015/babel support somehow or should that be part of the polymer build task itself?

[robdodson]

@NicolasRannou So that's one of the reasons why I think we're a little behind because we were hoping the CLI would provide us hooks to do that but the team says they're still working on it. So for our initial release we will not be supporting it but hopefully those hooks land in the next couple of weeks (that was the very rough estimate I was given). Once those hooks are in place then we'll provide something like a tiny gulpfile that hooks into the CLI and adds Babel

[web-padawan]

It is likely that Polymer team is about to discard Gulp and other build tools, like npm-scripts, in favor of CLI. In my opinion, encapsulating all the build tools into CLI is not a good idea.
There should be an opportunity to make different boilerplates and to pick only required plugins, which is unreachable when all tools are in one black box.
So I suggest keeping examples of using Gulp, maybe not in the PSK, but in a separate fresh boilerplate.

[oneezy]

@web-padawan I see your point. My main pain point at the moment is with missing BrowserSync.

I see why they're taking this approach to though. Simplicity.

Extracting there build process away from gulp and bundling it up with there very own Polymer commands will make it very easy for things to be done "the right" way.

At the same time, this also pulled me away from Meteor. There platform took a similar "black box" approach which made it hard for me to step away and adapt there process. . I.E. there way of handling live reload and not being able to use browser Sync. It can be a thin line. Hopefully these hooks will let us plug in easily to the CLI and add onto it for our custom workflows we've grown to love (or should I say, can't live without).

[web-padawan]

@oneezy This is the thing I disagree - forcing community to follow the way considered as "the only right". In fact, using CLI might be OK for typical cases. But what if the case is not typical?

It would be nice to split up the "black box" into separate plugins, like it is implemented in PostCSS. This could also inspire the community to join the development.

[chuckh]

My understand is Polymer-CLI will be able to be used by Gulp and extended by it. So I think we could be getting the best of both worlds. See below quote from Polymer-CLI readme.

Over time the build steps that Polymer-CLI uses will be available for use with Gulp, and the CLI will add hooks that let you extend it's functionality via Gulp.

See https://github.com/Polymer/polymer-cli#build

[robdodson]

@web-padawan @oneezy Chuck is correct. The plan is to provide gulp task hooks that anyone can use to modify the stream of files. And likely even provide a gulpfile version of what the CLI does for folks who can't use the CLI for whatever reason.

[oneezy]

Great!! :D

Keep up the excellent work guys!

[oneezy]

@robdodson , would you say it's safe to install PSK2 now for production use?

I'm reviewing the master checklist and it looks like the majority of everything is good to go.. (besides understanding how to use it :D

I'm just curious if there will be any important addons to keep an eye out for.
How far away would you say we've got for it's debut?

[jsilvermist]

@chuckh On the topic of separating the elements by folder or keeping them all together, I think the default elements should be bundled together for simplicity, as they don't have any other files which are strictly tied to an element which warrant being bundled together in it's own folder.

For this reason, I feel it would be best if all these elements were bundled in a folder such as main, simple, or something similar. Another option might be something that emphasises categorization of elements to improve sorting and naming without adding too much complication. (eg. app in src with folders for [pages, styles, addons])

In the README we could add a note saying for lone elements, just add it to the folder, but for more complicated elements (eg. paper-input) which link to files that won't be reused by any other element, or when there are child elements, make a new folder for the element in that case.

[robdodson]

@oneezy I think the biggest issue is that if you need to do image optimization there isn't currently a hook to do so. Nor is there a place to transform JS from ES2015. I had a meeting with the team today and they have a plan for giving us all the stuff we need. I think/hope they may have something for us later this week or next. Given that we may be very close to having what we need from the CLI team I think we can hold off on releasing PSK2 for another week or two. In the meantime, if you need gulp support you can keep using PSK1 and just swap out the paper-* elements for app-layout and page.js for app-route.

Tagging @justinfagnani so he's aware of our plans here.

[web-padawan]

@robdodson please pay attention to that Polymer requires using Babel without strict mode when transpiling ES2015. The reason is this issue in web-animations-lite used by neon-animated-pages. This bug is already known, just a reminder for those who are going to implement it in CLI.

[robdodson]

Thanks @web-padawan. They won't be implementing Babel in CLI, they're going to expose a hook so we can call Babel (or TypeScript, or whatever other compiler we want) from our build file. So we should have the option to disable strict on our end

[NicolasRannou]

OK thanks @robdodson

[johnlim]

Hi,

Any update as to how far out we are from PSK2? :)

[robdodson]

Still working with the eng team to get gulp support playing nice with CLI.
They've got a rough demo they built last week. We'll work to see if we can
integrate it this week.

On Sun, Jun 26, 2016 at 10:55 PM, John Lim Ding Wei <
[email protected]> wrote:

Hi,

Any update as to how far out we are from PSK2? :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#835 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABBFDUlNzqmiu7-sFDOg8WT6PztqUUFxks5qP2XAgaJpZM4IryDL
.

[robdodson]

Gulp build support is now work-in-progress at #857

[kito99]

Hey @robdodson, I have a couple of requests: please keep the "app" folder structure. The structure of the app toolbox really bothers me (hate having index.html and other app artifacts in the root).

Also, it would be a really good idea for someone to blog about the PSK and the app toolbox and how they're related. It took me a while to verify that the PSK isn't being deprecated altogether, since it's not on the official Polymer site anymore. (I was quite worried we were going to be stuck with the app toolbox, which is quite limited from a build tool perspective.)

[joaovieira]

Glad to see PSK2 with a similar structure to the app-drawer-template! (after spending some time trying to figure out which one was ahead...)

I've noted they both use the same polymer.json with the async fragments definition. However, PSK2 does not seem to load any of the fragments asynchronously (using importHref), but instead imports all the 'fragments' via sync HTML Imports. Or is there something else I'm missing?

(on a side note, when importing pages asynchronously, you loose the animations if they are defined in the pages themselves, hence I had to use the sync import on another app-drawer project as well. probable we could work around that by server-pushing the pages, though)

[robdodson]

Good call Joao. We should use importHref as that's inline with the Polymer
PRPL pattern.

What kind of animations are you referring to? Like neon-animations, or CSS
animations?

On Mon, Jul 25, 2016 at 4:15 AM, João Vieira [email protected]
wrote:

Glad to see PSK2 with a similar structure to the app-drawer-template!
(after spending some time trying to figure out which one was ahead...)

I've noted they both use the same polymer.json with the async fragments
definition. However, PSK2 does not seem to load any of the fragments
asynchronously (using importHref), but instead imports all the
'fragments' with via sync HTML Imports. Or is there something else I'm
missing?

(on a side note, when importing pages asynchronously, you loose the
animations if they are defined in the pages themselves, hence I add to use
the sync import on another app-drawer project as well. probable we could
work around that by server-pushing the pages, though)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#835 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABBFDUMTsrR5aQ30NLN2OemkPh5EiPYmks5qZJrGgaJpZM4IryDL
.

[joaovieira]

👍

Yes, custom entry/exit neon-animations using the animationConfig property (e.g. shared hero transitions).

[robdodson]

@joaovieira I've heard this complaint a lot regarding neon-animated-pages. I don't have a great solution off to the top of my head. It may be easier to just do the animations using the Web Animations API yourself :\

[robdodson]

btw I just did a push to move PSK2 over to using the PRPL pattern

[joaovieira]

Also noted the drawer-width attribute on the app-drawer-layout element doesn't do anything (https://elements.polymer-project.org/elements/app-layout?active=app-drawer-layout#properties) and should be using the --app-drawer-width custom CSS property on the app-drawer instead (https://elements.polymer-project.org/elements/app-layout?active=app-drawer), if necessary.

Keep up the good work!

[moderndeveloperllc]

Quick question. Will the cookbooks in the 1.x docs/ directory be updated to reflect the new gulpfile structure before launch, after launch, or left out permanently? Transpiling looks to be easier now, but CSP looks like it might be harder.

[robdodson]

@moderndeveloperllc planning to leave them out for now mainly because they're a huge maintenance burden. It got to the point where every time we made any change to PSK we had to audit all of the recipes to figure out if any of them broke :\

As for CSP being harder, that's an interesting question. @FredKSchott does polymer-build take any arguments for vulcanize to tell it to extract scripts?

[moderndeveloperllc]

@robdodson That's what I figured. Of course that's been replaced by tracking down build issues across three (or more) different repositories.

@FredKSchott There is an issue created in polymer-cli, but I think this may better be addressed in polymer-build where bundle.ts vulcanizes files in a couple of places. Maybe? But it would be difficult to bubble up all the options from that deep I would think. Perhaps in the PSK gulp file after rejoinHtml()?

[kito99]

@robdodson It might be better to just write code to automate the recipes (when possible); makes the auditing processor much easier ;-).

[FredKSchott]

@robdodson Thanks for reminding us about this issue, I've been meaning to look into what happens if your build stream includes splitHtml but not rejoinHtml. It should pull out all JS & CSS into their own files, replace them in the HTML with the correct script/style elements to load the new files, and then pipe it all to the build destination.

Soooooo... this might just solve CSP issues as it already is? I'll play around with it a bit this weekend and update this thread / that issue when I can say for certain.

[moderndeveloperllc]

@FredKSchott crisper has a few extras (variable output file name, defer and utf-8 in script tag, etc) that you might want to add, or refactor to use the library itself.

[FredKSchott]

Ah, yea splitHtml doesn't do that :)

Lets look into a crisper gulp-stream that can be run before splitHtml or after rejoinHtml. I think that will make a lot more sense than bundling it directly into polymer-build.

Until that exists, for a workaround could you copy everything into a pre-build directory and use the current crisper/vulcanize tools on it before starting build? (I haven't worked with crisper directly yet so I'm generally curious).

[wicope]

Hi.

I really like docs as mobile-chrome-apps.md and other projects intimately related as mobile-chromeapp-starter-kit

Have you got plan to upgrade the docs? Thanks and Good Day.

[robdodson]

@wicope no I don't think so. We're moving to a different model where there will be several template projects that work with Polymer CLI

Rather than create and maintain a guide on working with a mobile chrome app, I think it would be better for someone to turn that into their own CLI template. Templates are based on Yeoman, you can see a work in progress example here: https://github.com/PolymerElements/generator-polymer-init-custom-build

[chuckh]

Closing now that PSK2 has been released! 🎆 🎉

[johnlim]

Hi, may I know what is the psk2 branch for? I was of the assumption that that would be merged to master as the new PSK2.

[robdodson]

That was the direction we were heading in but decided instead to spin that work out into its own project: https://github.com/PolymerElements/generator-polymer-init-custom-build

Polymer Starter Kit is now based on the Polymer CLI app-drawer-template project. A lot of developers had already switched to the app-drawer-template because it used app-route, app-layout elements, and could be vulcanized/sharded without messing with gulp (instead just by running polymer build from the CLI).

What we found with PSK is that while a lot of folks liked the fact that it gave them a layout for free and had vulcanize already set up, there were also a lot of users who just wanted to play around with Polymer but got tripped up by the giant gulpfile in PSK. Most folks I talked to said they downloaded PSK and then started ripping out all the parts they didn't need. Furthermore, there was a ton of pressure to keep adding features to PSK (Babel, SASS, you name it) and it was difficult trying to balance a beginner friendly "starter" kit, with something that could also give everyone the production-ready template they sought.

We started creating recipes in the docs folder to show folks how to add these features but that also became a huge problem because every time we added a new feature to PSK we had to audit every single recipe to tweak them or make sure they weren't broken. As a result, work in PSK basically ground to a halt.

Polymer CLI gives us an opportunity to take a fresh look at things. Because Polymer CLI templates are really just Yeoman generators, it means we can write different project scaffolds that add in the features folks want, without trying to cram everything into one project. This is explained in more detail on our blog but basically PSK is now just a very simple starting point for anyone who wants to play with Polymer. We then pull PSK into the Custom Build project and add a gulpfile for folks who want to roll in additional build steps (like Babel or SASS or whatever). Furthermore, we could keep building generators that give folks the specific features they want. For instance, I would love for someone to build a generator that has TypeScript already setup and ready to go.

We're just now rolling out PSK2 so there's a lot of cleanup we still need to do. We'll be deleting those old branches and going through and closing issues that no longer apply to the new scaffold. Also I've recorded a Polycast which will come out (I think) tomorrow which walks folks through both PSK2 and the Custom Build project. And for anyone who wants to continue using the old PSK, you can always go to the releases section and grab a previous version. We made sure to tag a 1.4.0 version that had all the final bugfixes and whatnot before switching over to PSK2.

Sorry for the long explanation, hope that helps clarify some of what's going on! Happy to answer more questions if you have any :)

[johnlim]

@robdodson Thanks for the detailed reply! I'll need some time to digest all these but I'll be sure to post my questions here, if any. :)

Polymer Starter Kit 2 polycast is out! Watching it now....

[abdonrd]

New video! https://www.youtube.com/watch?v=HgJ0XCyBwzY