Publish sub-projects on npm, add them to package.json.

[timoxley]

Problem: The build process for polymer is clunky.

Solution: Publish individual components on npm, set up dependencies through each component's package.json, let npm manage gathering and building dependencies through npm's prepublish scripts.

This would get rid of this pull-all.sh hackery, allow pieces to be used in isolation, consolidate dependency management (you're already using npm to manage dev dependencies) as well as make it a more idomatic js project.

[dfreedm]

There is most certainly room for improvement in this area!

Bower is probably more appropriate due to the flat dependency list and implicit understanding of github paths.

I think pull-all.sh will continue to have a place in keeping a dev environment up to date, as that was the original purpose.

[timoxley]

oh, bower is a poor man's npm. You can get a flat dependency list using npm's peerDependencies and you can keep dev environments up to date by pointing at git repos instead of published versions (you'd have this set up on your development branch, and fixed versions on master/release branch). Idea would be to consolidate all the dev/release/test info into the package.json, rather than across both bower.json + package.json + pull-all.sh

[timoxley]

I'd be willing to set this up

[SamDuvall]

I'd love to have the polymer sub-projects curated by the polymer team in npm!

[dfreedm]

Ok, it seems like likely that there's enough demand to have components installable via npm as well as bower.

I'll set everything with peerDependencies to keep the flat structure we've been using.

[domenic]

Let me know if I can help in any way; this is a great idea not only in itself, but as @timoxley mentions, for simplifying your development process as well.

If there is something missing or problematic with npm for your needs, let me know and we (the npm team) can address it.

[csuwildcat]

@azakus heck, I'd be willing to bestow a lavish tribute of single barrel whiskey upon the Polymer team if they went one step further: published the polyfills à la carte on NPM and Bower, for consumption in part or whole ;)

[dfreedm]

After a long and fruitful conversation with @timoxley in #polymer, I think I've got a handle on what the npm/bower story should be.

All the platform polyfills and related bits should be published in NPM for others to develop easily. In addition, all the elements and polyfills should be available via bower for convenient client side consumption.

Right now we're focused on making sure our vision for the web component ecosystem is viable. I hope to address the npm/bower issues very soon.

[briandipalma]

Just thought I'd chime in and say that I have a similar use case to @cburgmer in https://github.com/Polymer/CustomElements/issues/84 where I'd ideally want an npm published built CustomElement package instead of a full Polymer package to allow targeted experimenting.

I used to be a firm believer in bower but I'm unsure if it will win. One JS package manager to rule them all provides good network effects so I would urge npm be treated as the equal to bower.

[timoxley]

@briandipalma in the meantime, you can get just the polyfills as the "polymer platform" (minus all the polymer framework stuff) via npm with npm install polyfill-webcomponents. See polyfill-webcomponents

[briandipalma]

@timoxley thank you. I was already aware of your project and I decided to use the Bower approach because I want to depend on only the code I require ( for the moment I wish to test Custom Elements and the polyfill support in older IE versions ). My ideal use case would of course be being able to npm install polymer-custom-elements and have it pull in all it's required dependencies.

This doesn't work at the moment due to the fact that one of it's dependencies (polymer-tools) is not a valid npm package. As you mention peerDependencies makes npm like Bower in that it has a flat dependency structure so I don't see why I should use two package managers but I will as long as projects keep using them...

[ericelliott]

Count this as my vote to make the npm/browserify story more usable.

:thumbsup:

[ghost]

IMHO, Browserify + npm is obsoleting bower… for Node.js developers anyway.

[knownasilya]

@wprl I totally agree, I find myself using bower less and less. Surprised this hasn't been done yet..

[glassresistor]

This is in high demand. The ability to browerify pieces of this project would be incredibly useful. No reason not to do both npm and bower.

[glassresistor]

Supporting both is the only way to get community wide support and I would say that the community is moving towards browserify.

[briandipalma]

For what it's worth I have a version of this polyfill that's two months old here on npm https://www.npmjs.org/package/customelements

[sjmiles]

We are working on improving various features around builds and packaging. This ticket has become stale though, so closing.

[ericelliott]

Is there a new place to track progress on npm packages?

[glassresistor]

+1

On Mon, Aug 18, 2014 at 6:24 PM, Eric Elliott notifications@github.com wrote:

Is there a new place to track progress on npm packages?

— Reply to this email directly or view it on GitHub https://github.com/Polymer/polymer/issues/326#issuecomment-52579174.

Mikela

[kristoferjoseph]

Why is this closed? Is the polymer team going to publish these projects to npm?

[kartesus-zz]

:+1:

[kolodny]

:+1:

@sjmiles Should someone open another ticket about this?

[mreinstein]

+1 I don't want bower for dependency management when there is so much more momentum and support behind npm.

[ericelliott]

Any progress? For now we can all use @timoxley's fork, but the Polymer team should really make this support first-class. npm is 5 times larger than Bower and growing faster as the Bower community flocks to Browserify and similar solutions.

[Nevraeka]

:+1: @ericelliott

@sjmiles - Can we reopen this or create a new ticket?

I know Polymer is moving in this direction but I would like to add that it's important to support both NPM & Bower until a clear 'winner' in the 'Package Manager Wars' emerges. This way, we don't dictate workflow to developers.

I am happy to volunteer some time to create NPM & Bower modules for each of the polyfills in webcomponents.js (:+1: @csuwildcat) and place them into separate repos. No one wants to duplicate work though so please update us on the progress. Thank you.

[ericelliott]

LOL @ "Until a clear winner" emerges. How much more popular does one have to be to become the clear winner? 10x larger? 20x?

I still think we should support Bower because there are enough users relying on it to make it worth supporting, but IMO, npm is already the very clear winner.

[Nevraeka]

Yep - That's basically what I meant by that :+1: @ericelliott

[erykpiast]

Is there any serious reason for which Polymer can't be published on NPM or it's only politics?

[erykpiast]

It's only substitute, but if you keep your packages in sync with the original repository, it's enough, for me at least :)

[robdodson]

@azakus would it be possible for us to publish the polyfills to npm now that we've moved over to webcomponents.js and everything is broken out into individual files? Maybe we could start with the polyfills and think about how to do the elements?

[ghost]

In case it helps anyone else, napa has worked well for me to manage dependencies on polymer stuff, keeping everything in package.json. An additional project dependency, but better than using two package managers in a project.

Still would like to see them added to npm :)

[kevinSuttle]

@robdodson Very interested in the outcome here.

[robdodson]

@kevinSuttle @JanMiksovsky is doing some interesting work in this area. Right now we're all focused on 0.8 stuff and getting element sets together for the upcoming I/O event in late May but I think after I/O we'll have time to revist this and hopefully start to come up with an npm solution.

[mreinstein]

Can we get this issue re-opened? The core issue hasn't been addressed and it doesn't seem like anyone is disagreeing on it's value.

[glassresistor]

+1

On Fri, Apr 10, 2015 at 8:47 AM, Mike Reinstein notifications@github.com wrote:

Can we get this issue re-opened? The core issue hasn't been addressed and it doesn't seem like anyone is disagreeing that it's valuable.

— Reply to this email directly or view it on GitHub https://github.com/Polymer/polymer/issues/326#issuecomment-91597825.

Mikela

[nwwells]

@robdodson it's now after I/O. What's the plan on this?

[mreinstein]

sweep it under the rug and forget about it apparently.

[robdodson]

@nwwells we've had discussions with the npm team and it seems like they're working to address the browser modules question for npm3. You can find meeting notes and issues here. Also there was a similar meeting between the Angular and npm team with notes available here.

The polyfill bundles have been published to npm: https://www.npmjs.com/package/webcomponents-lite https://www.npmjs.com/package/webcomponents.js

If there is strong demand for publishing the individual polyfills to npm we can look into that.

I've also been talking with some folks who have ideas about possible npm plugins that could give us the deduplication and conflict resolution we need but that's all still very early and will take more time to work on. I'll try to keep you all updated as we progress.

[mreinstein]

@robdodson thanks for taking the time to update!

[kristoferjoseph]

If there is strong demand for publishing the individual polyfills to npm we can look into that.

Do please consider the demand strong. For many the initial hurdle is adherence to the prescribed tools. Publishing individual modules for the polyfills would allow more users to benefit from this work as well as limit the scope of contributions to a single problem space.

[jokeyrhyme]

NPM 3 is in beta, and will be released soon: http://blog.npmjs.org/post/122450408965/npm-weekly-20-npm-3-is-here-ish

NPM 3 installs dependencies as flat as possible, unless there are conflicts: https://github.com/npm/npm/blob/multi-stage/CHANGELOG.md#flat-flat-flat

Once NPM 3 drops the "beta" flag, there'll likely be little reason to favour Bower.

[oleersoy]

Looking forward to seeing polymer on NPM :thumbsup:

[mreinstein]

I'm using polymer 0.5.x in several projects and holding off on upgrading to 1.x until I can use them as proper cjs modules from npm.

[oleersoy]

There's also Codependency in case Polymer wants to add optionalPeerDependencies. Could be useful for specifying additional components skins, etc.

[kevinSuttle]

What @kristoferjoseph said. Oh and @ryanflorence. https://twitter.com/ryanflorence/status/636555349303013376

[robdodson]

From what I've seen npm3 gets us part of the way there (it tries to flatten dependencies) though I think it still doesn't do dependency resolution (if there's a mismatch it just quietly gives you the latest, if I recall).

@addyosmani can correct me on this, but I believe the npm team has said they still have some work to do before they consider the front-end fully supported.

[oleersoy]

@robdodson can you give a simple examples example of the types of things that you think might cause issues if modules are made available on NPM? If we understand the the concerns in terms of a minimal example we can see what we can do in terms of using Browserify / Webpack / Vulcanize / etc to solve them.

[robdodson]

The primary concern with the older npm behavior of nesting everything is that HTML Imports won't be able to properly deduplicate dependencies. If x-foo depends on its nested copy of polymer (maybe version 0.5) and x-bar depends on its nested copy of polymer (v1.0) then loading both elements on the page would attempt to load Polymer twice, with two different versions.

The new behavior I saw in npm3 (admitted it was a limited test I did) was that when you tell it to flatten your dependencies, if it finds a version mismatch, it just automatically uses the latest version. This could lead to a different problem, that is, x-foo depends on paper-dialog 1.0 and x-bar depends on paper-dialog 2.0. npm decides to use paper-dialog 2.0 and then x-foo breaks in weird ways that may be hard to track down.

[oleersoy]

So what do we need NPM / any package manager to do?