Best practices for reusable component development.

[hourliert]

Hi,

First of all, thank you very much for this seed. It is wonderful and very useful.

I am new with polymer and I am trying to setup a good environment to develop a web app.
Firstly, I want to develop a reusable login-form component. It will depend on paper-material, paper-input and paper-button elements. I used this seed to create it.

Very quickly, I have noticed that developing in this seed-element project was not easy. There are no files watchers for polyserve reloading and no watchers to trigger wct tests (I hope a watch mode will be added to wct soon: Polymer/web-component-tester#32).

What is the best practice to develop a reusable component ? Should I include a git submodule directly in my webapp and use the webapp files watchers ? Should we add a watcher mode into polyserve ? Anything else ?

Thanks in advance.

[hourliert]

I find a solution to have tests reloading + browser reloading with polyserve. I use browsersync as proxy between the browser and polyserve. It works great.

I did a little gulpfile with some useful tasks. I could share it if needed.

[notwaldorf]

@arthurevans Is there a place where we can put this sort of info in the docs?

[JohnRiv]

Polymer Team - what is your process for propagating updates to this seed-element to all of your other elements?

[ebidel]

What do you mean?

On Fri, Oct 23, 2015, 6:48 AM John Riviello notifications@github.com
wrote:

Polymer Team - what is your process for propagating updates to this
seed-element to all of your other elements?

—
Reply to this email directly or view it on GitHub
#53 (comment)
.

[filaraujo]

Well taking seed-element as the basis for our components. If each element is incapsulated with its own tests, demo pages and assets, how do you maintain a jslint, jscs, process against those repos? Doesn't seem that each element gets its own testing setup, which leads us to believe that is managed by an external repo/process/submodule/whatever.

[ebidel]

The Polymer team has a CI runner that runs tests against all of our element repos. That's particular to our case where we're vending 100s of resuable elements. Unless a developer using seed-element is doing the same, I'm not sure that's a problem they'll run in to. wct can be used for individual project setups.

Note sure if this is what @JohnRiv was after though...

[JohnRiv]

Thanks for the reply @ebidel. To give more context of where we're coming from, we have one project with just under 200 custom components we created ourselves, and that project has lots of coding standards enforced via jshint, jscs, etc., as well as additional tools to run tests via wct, gather coverage info via web-component-tester-istanbul, etc. So in that project, whenever we want to add a new tool to assist in the development process, we do it in one spot in the project, and then all the components benefits because they're all built directly into the project

Recently, we've begun the process of pulling some of those components out into their own repos and hosting them internally so other projects can use them (we've done that for about 10 so far). We have our own seed element that includes tools for running these coding standards on developer's machine and our CI environment, but if we make a change (for example, the usage of web-component-tester-istanbul is very recent), we add that to our seed element first so any new elements created will have it, and then we have to manually add that to each component, which is obviously not maintainable.

I was considering creating our own version of load-common-gulp-tasks and making that a dependency for all of our polymer repos, but would prefer to borrow from what you're doing. So it sounds like we should take a deeper look at ci-runner and how we can integrate that into our CI environment?

[ebidel]

@azakus is our expert there. I'm afraid I don't know much about our setup.

[filaraujo]

thanks eric

[dfreedm]

FWIW, I'm actively trying to deprecate our homegrown CI Runner for Travis CI to use more standard tools.

I've written up a sample config you can copy/paste into any element you want to test on Travis CI: https://github.com/Polymer/tools/tree/master/travis

[JohnRiv]

Thanks @azakus, that's helpful. Do you have a plan for how you'd integrate other tools with that (e.g. polylint, JSHint, JSCS, etc.) to enforce coding standards among all of your components? Or is that still something you're working through?

[dfreedm]

Still working on that, but since Travis CI considers a test failed if any program's exit code is >0, you can just chain them in your config: jshint *.js && polylint my-element && wct

[dfreedm]

Or, use separate lines in the travis.yml

script:
- jshint *.js
- polylint
- wct