Tools: Polymer init element could integrate better with existing projects

[QuackMartins]

I wish we could run polymer init element for creating elements in an existing project

Example how it could be, running from /projects/polymon:

> polymer init element
> Create a new project? #(y/N)
> Bower.json location: #./bower.json
> Element name: #poly-ball
> Element Directory: #app/elements/poly-ball

[QuackMartins]

Would a PR be welcome?

[justinfagnani]

Yes definitely! though we really should have our long term plans outlined in the repo for contributions like this.

In this case we've always envisioned a separate polymer gen command that would generate new elements and possible other things. The difference between init and gen being that init (somewhat like bower init, npm init, and git init) would be only for initializing a new project from an empty directory.

It's not very hard to write a new command, and it could reuse a lot of code from init.

[oneezy]

+1
Sounds legit!

[rpapeters]

Creating an element project (having it's own bower_components) inside an existing project results in having (many) duplicate files, which of course is not desirable. So better integration would be a big plus!

[isochronous]

This is symptomatic of what is probably my single biggest problem with the Polymer ecosystem as it is today. There's a massive amount of documentation about polymer cli, but it all seems to assume a green-fields, blank slate environment. We're trying to add polymer to a large existing .NET MVC application, and a lot of the "features" of the CLI actually work against us.

For example, the whole "components are siblings" thing. While it's great that polymer serve maps folders to guarantee a sibling structure during development, it's not like we can use that server in production... and yet there's absolutely no information on how to deal with this "import paths don't match paths on disk" issue in a real production environment. So we can either use polymer serve and have a nice dev experience that won't work in production, or we use actual paths and lose the ability to use polymer serve. While I suspect that bundling might mitigate that, bundling removes the benefits of Http2, and even then it's not clear if (what was) vulcanize does the same directory aliasing trick as polymer serve. Will those bad paths be rewritten for us, or do we have to fix them before bundling? It's left up to us to figure out.

I have no hard data to back up this assertion, but my gut feeling is that adding polymer to an existing project is (or would be) a more common use case than creating an entirely new project from scratch, and yet there doesn't seem to be a single bit of information in the docs on doing such a thing. Some different templates that are based on an "existing project integration" perspective would be really useful. As it is, it's left up to us to deal with the problems that the polymer team punted on, and especially with polymer and polymer-cli recently being fast-moving targets, it's been really frustrating trying to figure out how to deal with these glaringly obvious issues.

I'm sorry for complaining about this, as I know the Polymer and CLI teams have put in a massive amount of work, especially recently, but these seem like use cases that should have been solved pre-1.0.

[MeTaNoV]

I will start a small freelance project with the same need, that is, providing a practical way to develop und bundle a somehow semi-complex Polymer Web Components to be integrated into a non-Polymer environment. If polymer-cli does not answer to this need, I hope polymer-build (https://github.com/Polymer/polymer-build) provide the necessary flexibility to address it!

[isochronous]

Polymer build is part of the polymer cli, but I think I know what you mean. Thanks!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.