Polymer: 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:

[wprl]

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 [email protected]
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?

[wprl]

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 [email protected]
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?

[tilgovi]

I think you should just publish them and let the community help discover and work out these issues when they appear in practice, rather than trying to predict them up front.

[robdodson]

@oleersoy it may be the case that there needs to be a dependency conflict resolution flow, similar to what bower does now.

[oleersoy]

So what would bower do when x-bar depends on paper-dialog 1.0 and x-foo depends on paper-dialog 2.0?

[robdodson]

It asks the developer to resolve the issue:

[oleersoy]

What happens when both of the jquery dependencies are mutually exclusive WRT the corresponding consumer APIs?

[robdodson]

Then you can't use both components at the same time in the browser. That's what I'm getting at. It's really important to know this up front otherwise it could lead to weird bugs.

[oleersoy]

So does polymer expect developers to update components, look for a different component, or an entirely different solution each time there is a collision?

[robdodson]

My understanding is it's not just Polymer, it's any situation in which you want to load competing versions of the same thing in the browser. The above example is taken from a jQuery project, for instance.

[oleersoy]

IIUC browserify has solved this by generating an IIFE for each component and injecting the corresponding dependencies.

[oleersoy]

There's also Atomify:
https://www.npmjs.com/package/atomify

[robdodson]

I don't think that'll work for custom elements though. You can't have two different x-foo tags registered in the browser at the same time.

[oleersoy]

OK - I think I see what you are saying. So if we have two different paper-dialog versions pulled in as transitive dependencies, Polymer will get confused when attempting to find the implementation for the paper-dialog?

Any chance that Polymer might support version tags on the elements? Say:
<paper-dialog:2.0.3>?

[robdodson]

So if we have two different paper-dialog versions pulled in as transitive dependencies, Polymer will get confused when attempting to find the implementation for the paper-dialog?

Not quite, it'll register whichever one loads first, then you'll get an error when the second one loads and it attempts to register it.

Any chance that Polymer might support version tags on the elements? Say:
paper-dialog:2.0.3?

That's not really up to Polymer, the underlying Custom Elements spec would need to change for something like that.

[wprl]

If a page depends on two components that register the same element, could a warning or error be generated? It seems to me a runtime error would be sufficient. I would gladly give up install-time reporting of dependency issues for better mom support.

On Aug 31, 2015, at 8:12 PM, Ole Ersoy [email protected] wrote:

OK - I think I see what you are saying. So if we have two different paper-dialog versions pulled in as transitive dependencies, Polymer will get confused when attempting to find the implementation for the paper-dialog?

Any chance that Polymer might support version tags on the elements? Say:
paper-dialog:2.0.3?

—
Reply to this email directly or view it on GitHub.

[robdodson]

@wprl The page itself will throw an error saying something like "attempt to register 'x-foo' but 'x-foo' already exists".

[oleersoy]

It would be great to see @wprl recommendation included, so that we can at least get things up on NPM and start the party. However if we get warnings and have to deal with conflict resolutions frequently when combining components from The wild then a lot of us are going to run away screaming, call our mom, etc.

There are a number of solutions that would allow Polymer to look up the corresponding component implementation via the tag element and component version:
(And I'm sure others will come up with more elegant ones, especially if the packages are on NPM):
1) Use a data-polymer-version attribute on the element
2) Include the version number in the element name (I'm sure there's a perfectly legal way to do this)
3) Have polymer read version meta data for each component (Could be generated into a manifest from package.json), in which case both the parent element and the version of the child would have to be used as keys for the lookup. In other words Polymer would have to understand the elements context, such that it could lookup the right version for the implementation.

Number 3 works for transitive dependency conflicts only though.

[adamreisnz]

I'm late to the party, but found out about Polymer and wanted to try it, only to find that it's (still) only installable via Bower or by hand. Having just recently closed the book on Bower and moved to npm for all front-end package management, I really don't want to be forced to go back to Bower.

@robdodson any update as to the status of npm support?

[Nevraeka]

@adambuczynski not yet (please correct me if I am wrong @robdodson). As Rob stated earlier - NPM 3 gets us half way there. We prob won't see official packages until at least NPM 4 (see the notes here. It might be possible to load these with WebPack or StealJS but I have not seen solid examples to solidify that theory yet.

[adamreisnz]

Thanks @Nevraeka

[ericelliott]

Looks like the reasoning boils down to the idea that "Polymer elements and Web Component packages tend to ship code that is only going to be used in the browser". This was basically the founding philosophy of Bower, which has, IMO been proven wrong, which is the primary reason that Bower has been abandoned by so many.

Granted, front-end code does have some concerns that don't belong on the server, but in practice, the real number of those concerns is tiny compared to concerns that can (and should) be shared across client and server.

That front-end-only approach is a non-starter for those of us writing universal apps (which I'd expect to see a LOT more of in 2016).

It's a little sad that the best known and supported framework with a foundation in standards-based web components is currently unusable for universal apps.

[jokeyrhyme]

Has dropping link[rel=import] in favour of ES2015 modules or something JavaScript-powered been discussed? It seems like it'll never be implemented outside of Chrome, and it seems to be a major blocker for using npm 3.

[addyosmani]

Hey folks. Getting official packages for Polymer published to npm is still a priority for us this quarter and we've been investigating it for some time. There's no intention to drop HTML imports as they're a core part of our developer experience.

Some background to previous comments: Polymer requires flat packages more than other JavaScript libraries due to the global Custom Element registry. Browsers have a global environment and not all libraries can be safely loaded in duplicate. This can be tricky in the npm ecosystem because it's common to have multiple versions of X with irresolvable conflicts. We also want to avoid having Polymer apps out where bloated due to multiple versions being pulled in without deduping being factored in.

To work around some of these issues, we're exploring additional tooling that would smooth over some of the rough edges we're unlikely to see resolved until future versions of npm. It's unfortunately not as simple as just running npm publish on all our library and elements, otherwise we'd have done that a long time ago :sweat_smile:.

[ericelliott]

Thanks for the update, @addyosmani -- I'm happy to hear that this effort is still a focus.

[jokeyrhyme]

| framework | npm | bower |
| --- | --- | --- |
| react | 9346 | 128 |
| angular | 5574 | 5160 |
| ember | 2880 | 262 |
| polymer | 361 | 556 |

@addyosmani I'm naively assuming cause-and-effect here, but it seems like JS-import frameworks are easier for the community to develop for, compared to Polymer which seems to be the lone HTML-import framework. Even lodging CSS in npm is easier because url(...) in CSS is relative to the current file. I love the amount of 1st-party work that is going into Polymer, but it seems like JS-import frameworks have an easier time developing communities.

I'm not trying to turn this into some kind of meaningless big numbers contest, but surely this is something to investigate and consider. If you can link to mailing lists, etc where link[rel=import] has been discussed as a no-compromise feature, that would help me catch up with your thinking. Cheers.

[oleersoy]

Hi Addy,

I've asked about this before on the list, but maybe I did not detail the scenario enough or too much :). Suppose I find some components in the wild. Component A and Component B.

Both of these require Component C, except Component A requires version 1.2 and Component B requires version 2.3. Does this mean that effectively I either have to update Component A to use version 2.3 or Component B to use version 1.2 or just forget the whole thing?

WDYT?

Cheers,
Ole

[robdodson]

I've asked about this before on the list, but maybe I did not detail the scenario enough or too much :). Suppose I find some components in the wild. Component A and Component B.

Both of these require Component C, except Component A requires version 1.2 and Component B requires version 2.3. Does this mean that effectively I either have to update Component A to use version 2.3 or Component B to use version 1.2 or just forget the whole thing?

You'll have to resolve the conflict. the reason is because the browser can't have multiple versions of the same component registered on the page.

[adamreisnz]

As @robdodson said, this is a choice that the developer has to make, and they would have to decide what package and version to use in the end.

Personally I don't think that situation should occur too often. If Component A requires 1.2 while version 2.3 is already out, then it would be an indication to me that Component A is either outdated and hasn't been maintained properly, or at least hasn't had its dependencies updated for a long time. In that case, i would probably steer away from that package and look to see if there's an alternative, or fork it and update it myself if I'd really want to use that particular component.

If it's just a difference in minor or patch version, it should be safe to use the last version of Component C according to semantic versioning.

[oleersoy]

What both of you are saying is true, but only because Polymer is designed to make it true. Polymer could support a versioned component registry (The same way Node supports different versions of transitive dependencies) and then the need for a custom registry goes away.

Also what if the assumption that conflict resolution is going to be required infrequently is off (Although it may be a self fulfilling prophecy assuming this is not fixed)?

The thing is we don't know that Component A has to be updated. And it's not necessarily a simple change. There could be several other components that need the version 1 API of component C and now all these have to be patched as well.

Polymer could print a notification on the console warning about it, and let the dev do whatever she wants to.

If you have looked at a versioned component registry and said that it's impossible for reason A, B, C, then fine, but if that's not the case then you are potentially sending the entire community in the wrong direction.

[robdodson]

What both of you are saying is true, but only because Polymer is designed to make it true. Polymer could support a versioned component registry (The same way Node supports different versions of transitive dependencies) and then the need for a custom registry goes away.

It's not a Polymer decision, this is how the underlying standard for custom elements currently works. The folks working on the specs realize there's more than can be done to give developers additional control over the registry but my understanding is they want to get at least a v1 agreed upon and implemented by all the browsers so we have a foundation to build upon and add new features to.

Polymer could print a notification on the console warning about it, and let the dev do whatever she wants to.

This is what bower does today

If you have looked at a versioned component registry and said that it's impossible for reason A, B, C, then fine, but if that's not the case then you are potentially sending the entire community in the wrong direction.

Not impossible, just not part of the existing spec as I understand it. Again, we're trying to get all the browsers on board and implementing the parts of web components that they can all agree on, then we can continue to iterate.

[oleersoy]

Have you looked at the number of packages in the Node ecosystem ATM? Did you look at the rate at which it has grown? Does Polymer intend / desire this level of success? If every time someone wanted to install a package using NPM they received a ton of warnings about transitive dependencies then we would not even be discussing NPM right now.

Polymer is pushing boundaries either way. Why not just make something that devs love and then worry about getting other browsers on board?

[tilgovi]

Tooling exists already for developers worried about redundant dependencies,
transitive out-of-date dependency checking, etc.

This is not a scenario where I expect everything will be awful and broken
all the time. This is a scenario where some people, playing a little toward
the bleeding edge, may hit some snags and have to work it out as a
community.

I feel like not shipping the modules is blocking the whole user community
from helping to bake and test this path, though.

Use npm and if the community experiences pain the community will deliver
solutions.

On Thu, Jan 28, 2016, 15:17 Ole Ersoy [email protected] wrote:

Have you looked at the number of packages in the Node ecosystem ATM? Did
you look at the rate at which it has grown? Does Polymer intend / desire
this level of success? If every time someone wanted to install a package
using NPM they received a ton of warnings about transitive dependencies
then we would not even be discussing NPM right now.

Polymer is pushing boundaries either way. Why not just make something that
devs love and then worry about getting other browsers on board?

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

[adamreisnz]

I feel like not shipping the modules is blocking the whole user community
from helping to bake and test this path, though.

I agree, and the lack of npm support is the only reason I am _not_ using Polymer yet.

[ericelliott]

Use npm and if the community experiences pain the community will deliver
solutions.

I'm inclined to agree with this. I think that if the packages had been published in 2013, solutions would exist already.

[addyosmani]

I've put together an (interim, experimental) npm package containing all official Polymer elements here: https://www.npmjs.com/package/npm-polymer-elements. This is just an idea, so please test.

Notes:

• This is an uber-package covering the current releases for Iron, Paper, Gold, Neon, Platinum elements.
• This package preserves the directory structure needed to get everything working (npm3 currently can't require a completely flat structure as we need). You can just npm install the package and start including elements. @samccone helped me verify it works as expected.
• This package isn't perfect by any means but does work. There are directories included that I'd otherwise be including as completely separate npm dependencies, but this would require changes to Polymer element source paths.
• This package is not 'official official'. I'd like to see if the current proposed interim solution works for folks. If it does, I'll pitch this as something we include in our element release process so it actually gets updated accordingly. We still want to eventually properly support publishing atomic packages to npm rather than this hack. It should only be viewed as a short term solution.
• README is minimal atm. I'll flesh out further depending on where we take this.

[sjmiles]

I re-opened this because there is a lot of discussion here that was in zombie form. Sorry we got stalled on this issue.

[tilgovi]

\o/
Thanks, @addyosmani.

[sjmiles]

After asking around, the information I have is that npm currently cannot require a flat dependency structure and will begin nesting modules when it encounters a conflict, and that this basic issue prevents us from simply switching to npm, as we would probably otherwise just do.

[chuckh]

@addyosmani what about including Google Web Components and Modules too? (did notice marked-element got installed anyway)

[addyosmani]

@chuckh we could try it out. I'd like to see how well this current set works and if we don't find too many thorns, will add in GWC, Molecules and maybe Firebase elements to the next test :)

[jokeyrhyme]

npm currently cannot require a flat dependency structure and will begin nesting modules when it encounters a conflict

@sjmiles does Polymer itself support multiple versions of the same component? if not, then why is it such a big deal if npm nests when it encounters version conflicts? it seems to me that you'd want the developer to intervene in any case, to get back to 1 version of each component

[addyosmani]

In case anyone would like to test the experimental package I published, here's a Material Design sampler page (based on the one by @ebidel) that just uses npm: https://github.com/addyosmani/npm-and-polymer-demo.

Note: This all gets a lot more complex once you start wanting to pull in other third-party elements.

[sjmiles]

@jokeyrhyme My understanding is that if npm nests, it's considered a successful install, but the packages from the web application's perspective would be broken. Yes, you are right we want to developer to intervene at this point, but it's not clear how to alert them to the problem.

[nwwells]

How about a postinstall script that checks for the condition and then reports an error? Haven't really thought this through all the way and can't test it out just now...

On Jan 28, 2016, 21:23 -0500, Scott J. [email protected], wrote:

@jokeyrhyme(https://github.com/jokeyrhyme)My understanding is that if npm nests, it's considered a successful install, but the packages from the web application's perspective would be broken. Yes, you are right we want to developer to intervene at this point, but it's not clear how to alert them to the problem.

—
Reply to this email directly orview it on GitHub(https://github.com/Polymer/polymer/issues/326#issuecomment-176529076).

[justinfagnani]

We don't just need to check for nesting errors, we need to copy files around to match our package naming. npm very unfortunately doesn't have namespacing and several of our package names are already taken, including polymer (I've tried to contact the owner, all dependents seem like they want our project), polymer-js (a fork/bundle of Polymer, maybe we could get it), and a bunch of paper- elements.

This means we either have to remap package names as a post-install task, or use scopes, which are unfortunately not very user friendly and still would require some cleanup to remove the scope name from the path.

Remapping package names would require steps like:

> npm install polymer-polymer --save
> polypackage polymer-polymer polymer // maybe re read config out of package.json

and then some folder like browser_modules/ will contain polymer/

Otherwise we could try to use scopes, but:

• Scoped packages don't show up in npm search :(
• Scoped packages are installed in subfolders of a scope folder. We'd have to either import them as ../@polymer/polymer, or run a similar remapping step as above

This situation is just bad. npm on its own is nowhere near ready for frontend packages.

[nwwells]

None of the problems you highlighted have anything to do with the frontend. They have to do with the fact that the polymer project didn't grab all the package names on npm because bower was selected as the package manager of choice.

Not judging anyone. Just pointing out that this isn't a problem with the design of npm's dependency resolution.

[justinfagnani]

We don't have a closed set of packages, we add elements to paper-_, iron-_, gold-*, etc. There is no possible way to reserve all the names. The polymer package name was taken over 3 years ago. Having organizations and namespacing on Github means that Bower has avoided these problems. Bower also lets a package remap its dependencies, making it much more likely that you can have a usable packages folder without additional tools.

[justinfagnani]

Right, but that changes the path the packages are available on disk, and so requires changing how things are imported, or a post-install remapping tool.

[ericelliott]

npm on its own is nowhere near ready for frontend packages.

I've been using npm for front-end packages for years, with zero problems. I use a project build step to put files where they're expected to be for execution. Since I'm already compiling from ES6 with Babel, this extra "remapping" step is a non-issue.

[justinfagnani]

We try to keep things as simple as possible so that we don't require much tooling, and so far Bower has had a much simpler workflow: install, import. That's why our focus has been on Bower - for most of our users, it's easier.

Many of our users are either not so advanced in the node/npm ecosystem, or are reluctant to take on the extra burden of build steps and additional tools, and some are already unhappy with even needing node and Bower.

IMO, you can use Bower and npm together well enough, especially if you're already maintaining build steps to convert npm dependencies for use in the browser. I do this for my projects (including exposing the JS as HTML imports). Considering that this is a fairly incremental burden on npm-centric projects, as you point out, it's probably not been an unreasonable tradeoff to let those most used to and capable of dealing with build configurations figure out how to integrate Bower into their setup.

By the way, my comment about npm not being ready for frontend is really tied to the part "npm on it's own". We both have build steps that we pair with npm to make it work. With Bower you don't need that. Not that Bower doesn't have it's own issues.

The equation has been changing over the last few years, but I still don't see that we're close to having an npm workflow that's as easy to understand and use as the Bower workflow. Maybe we need to not let that be a blocker. One obvious short-term option is that we publish everything under the @polymer scope to get things started and let our npm-using community help figure out how to smooth over the rough edges. Scopes in npm are still rough themselves, including the killer that scoped packages don't show up in npmjs.com search, so we probably wouldn't advertise this option yet. We also need our own tooling to help manage releases with well over 100 packages to publish regularly.

It's on our short list to figure this out, so we'll have movement very soon.

[nwwells]

Justin, I know you mean well, and I love polymer. The team has put together something amazing. But it's comments like "It's on our short list to figure this out, so we'll have movement very soon" that force me to conclude that the team behind polymer doesn't want to build an community around it.

You people (regretfully I have to say it that way) are neglecting the user you don't see. You assume that your users need hand holding and explicitly don't want to support those who don't. This has nothing to do with Bower vs npm.

I got excited when 1.0 came out because I thought it meant that I'd be able to champion polymer in my projects. Nope. Turns out that you just plain don't think I'm worth supporting.

Sorry guys, I'm out. I'll check back with you in a couple of years, maybe.

On Jan 29, 2016, 17:29 -0500, Justin [email protected], wrote:

We try to keep things as simple as possible so that we don't require much tooling, and so far Bower has had a much simpler workflow: install, import. That's why our focus has been on Bower - for most of our users, it's easier.

Many of our users are either not so advanced in the node/npm ecosystem, or are reluctant to take on the extra burden of build steps and additional tools, and some are already unhappy with even needing node and Bower.

IMO, you can use Bower and npm together well enough, especially if you're already maintaining build steps to convert npm dependencies for use in the browser. I do this for my projects (including exposing the JS as HTML imports). Considering that this is a fairly incremental burden on npm-centric projects, as you point out, it's probably not been an unreasonable tradeoff to let those most used to and capable of dealing with build configurations figure out how to integrate Bower into their setup.

By the way, my comment about npm not being ready for frontend is really tied to the part "npm on it's own". We both have build steps that we pair with npm to make it work. With Bower you don't need that. Not that Bower doesn't have it's own issues.

The equation has been changing over the last few years, but I still don't see that we're close to having an npm workflow that's as easy to understand and use as the Bower workflow. Maybe we need to not let that be a blocker. One obvious short-term option is that we publish everything under the@polymer(https://github.com/polymer)scope to get things started and let our npm-using community help figure out how to smooth over the rough edges. Scopes in npm are still rough themselves, including the killer that scoped packages don't show up in npmjs.com search, so we probably wouldn't advertise this option yet. We also need our own tooling to help manage releases with well over 100 packages to publish regularly.

It's on our short list to figure this out, so we'll have movement very soon.

—
Reply to this email directly orview it on GitHub(https://github.com/Polymer/polymer/issues/326#issuecomment-176998098).

[samccone]

@nwwells please remember that is an open source effort run by other humans, so please be respectful when communicating.

Any brainstorming or even prototypes of ways to solve this, such as what @addyosmani put together would be immensely helpful.

Thanks for your interest, and looking forward to any future ideas you may have :v:

[justinfagnani]

@nwwells I'm sorry that you're reading this as saying that we don't want to support you. We do.

From my point of view the problem here is exactly what to support. As far as I can tell, here's no standard plug-and-play standard npm configuration that supports browsers like there there is with Bower. Every npm project uses npm + other tools to get the job done, and there are a great many variations on those other tools. It seems like the required practice is to use npm to get the bits to disk, then build steps to massage and bundle the bits to be loadable and usable in a browser.

In my projects where I'm a user of Polymer and npm libraries, I just add Bower to the mix to get the Polymer (and some other frontend packages) bits, and roughly the same build steps to prepare things for the browser.

Here's how I've thought of the various users of Bower and npm, before and after adopting Polymer:

Before Polymer:
bower -> usable project
npm + build steps -> usable project

After Polymer:
bower -> usable project
npm + bower + build steps -> usable project

The observation here is that npm users already have and understand a more complex checkout and build process, and presumably can integrate Bower to pull in Polymer. Maybe it's the assumption that adding Bower to an npm project (that is already integrating several tools by necessity) is acceptably small extra step that's wrong. If so, I hear you, and we've been hearing this much louder and more frequently recently. This is why it's on our short list (besides having wanted to figure out how to best support npm already) to figure out.

Do you have any opinions on the option for starting of just publishing our packages, without necessarily having the whole workflow figured out? That would at least let npm users get rid of Bower and have a single dependencies list. I do think that the perfect has been the enemy of the good enough here, and this could be a way to make progress and get feedback.

[jokeyrhyme]

I'd suggest publishing to a scope, and asking the npm registry folks to show all public packages in search results, regardless of scope.

[ericelliott]

Do you have any opinions on the option for starting of just publishing our packages, without necessarily having the whole workflow figured out?

I think this is a good strategy. Also, I don't believe that Bower was ever necessary. I believe that a simple, plug and play solution could have easily been built on the foundation that npm provides.

npm allows you to create custom fields for any metadata that might have been required, and task runners for any build steps necessary to shuffle things to where they need to be. You could even create a simple CLI to hide the details from users who don't want to peek under the hood and see that maybe there's a "build:polimer" npm script getting run on install.

I also agree that refusing to do something because you think most of your users won't understand it does a great discredit to most of the potential users of Polymer.

"Front-end" engineers are not simply a large group of idiots incapable of figuring things out.

The key is to make it as easy as possible, but not so easy as to make it tricky to integrate Polymer into a typical JS project using ES6 modules & npm.

Let's just call it like it is: Polymer made a bet that "front-end" modules had special needs that were not required of Node modules, and that it would be difficult to built front-end software using npm as the package manager. The success of tens of thousands of projects using npm for both front-end and universal JavaScript projects proves that the bet was wrong.

In the Universal JavaScript ecosystem, there is no front-end/backend. There is only universal.

[ericelliott]

I'd suggest publishing to a scope, and asking the npm registry folks to show all public packages in search results, regardless of scope.

I agree with this. They should filter search based on public vs private, not based on scope.

[oleersoy]

With everything that has been said so far, there is still a very tight bottleneck ahead for anyone who wants to build / prototype / experiment / extend polymer.

Suppose you design a new Calendar element / component. It pulls in a bunch of other polymer components. You publish it.

I try to use it in a broader more aggregated project and after running:
npm i your-calendar

I get several warnings that the component and several of the sub components are incompatible with some of my main components and their sub components. This is a guaranteed frequent scenario and it's going to put a massive drag on the entire ecosystem. There's a reason why Eclipse runs on OSGi.

[jokeyrhyme]

I get several warnings that the component and several of the sub components are incompatible with some of my main components and their sub components.

@oleersoy: this crops up with any component-first framework, not just Polymer. Polymer has a leg up here because it has such an enormous first-party component library, compared to any other framework. I think component version compatibility is the least of Polymer's problems currently.

[nwwells]

@samccone I'm sorry if I came off as disrespectful. My intent was to be respectful, an intent I thought I had accomplished. I hope you read the following message as respectful also. I think what you're calling disrespectful is simply me expressing frustration. As noted at the top of my comment, I have nothing but respect and admiration for what the polymer team has accomplished.

@justinfagnani The problem with the npm vs bower debate is that it's comparing apples to oranges. Npm is a package manager with a little bit of tooling to make it easy to run scripts, including build tools. Bower is a package manager + a build tool. Many people choose npm (including myself) because it is independent of the target environment (browser or server). It is this, in fact which makes me value npm so highly: it maintains the SRP, mostly.

Bower doesn't. That's not to say it's a bad tool or the people that use it or made it are bad. It's a purpose-built tool, which is great. There are many reasons I could be persuaded to use bower, in fact. Be that as it may, it isn't always the right tool, and even if it is, someone who's myopic about npm may simply have the power to override everyone's best judgement and pick it. That's not right, and it's not good, but it's often reality.

With this (my perspective) as backdrop, let me walk you through my reaction to your statements:

As far as I can tell, here's no standard plug-and-play standard npm configuration that supports browsers like there there is with Bower.

That's right, because if there was, it would be a violation of the SRP.

It seems like the required practice is to use npm to get the bits to disk, then build steps to massage and bundle the bits to be loadable and usable in a browser.

Yes. Because the appropriate choice of build system is specific to each project.

The observation here is that npm users already have and understand a more complex checkout and build process, and presumably can integrate Bower to pull in Polymer.

Here's where you lose me. Just because I understand a more complex build process means that I am required to have two package managers if I want to use Polymer?

Maybe it's the assumption that adding Bower to an npm project (that is already integrating several tools by necessity) is acceptably small extra step that's wrong.

There you go. yes. Here's the difference: new clones of my project used to just run

git clone $project
npm install
npm start

Now they have to run

git clone $project
npm install
npm start
# build failure. Maybe if the build system has really good error messaging
#      it tells them, "hey, did you install bower?"
# confusing debugging time because aforementioned error messaging probably doesn't exist.
# eventually give up and ask someone else, which causes _them_ to context switch
# "Oh, yeah. You've got to bower install"
# "What's bower?"
# "Oh, it's a package manager"
# "You mean like npm?"
# "Yeah"
# "Well, why do we have 2?"
# "Well, polymer, which is this awesome web component driven framework 
#         requires that we use bower, hopefully just for a little while longer."
# "That's dumb"
# "Yeah, but we deal with it."
# "OK. w/e"
npm install -g bower
bower install

If so, I hear you, and we've been hearing this much louder and more frequently recently.

Great! I hope you don't hold it against me that I'm belaboring the issue. I feel bad about doing it actually, but there still seems to be some confusion about what an ideal workflow on npm + (insert build tool here) looks like. I'm happy to provide examples and answer questions about it.

Do you have any opinions on the option for starting of just publishing our packages, without necessarily having the whole workflow figured out?

Yes, that's a great start. In fact, that solves this issue from my perspective. Ideally you wouldn't have to use a scope, but that's a problem that can be worked on in parallel.

After you can get any polymer package on npm, then we can solve integrating with build systems, whether that's browserify, webpack, or whatever. If the polymer project governance (i.e. "You people") decide that browserify (or w/e) is a pain, or can't be supported in a general way, then great. We (the devs) can handle that on our own.

_Read on for rants about the definition of "community". You have been warned._

---

Finally, (totally off-topic for this issue) I wish there was a lot less "us" and "them". It seems really off-putting to me. I'm a member of the community, which means I'm part of the team. I'm one of those "other humans". The React community does this very well. In fact, I was politely, but firmly corrected on one issue I commented on for implying that "they" (meaning the Facebook devs who maintain/support React) weren't paying attention to it. A member of the community (non-Facebook employee) said something like, "Well, if it bothers you so much, submit a PR. These people don't owe you anything."

So, in the spirit of community cooperation (:D), am I clear about my use case here? Any questions about the role of npm?

[miztroh-zz]

I don't see a problem offering npm as another delivery method, but I'd hate to see it replace bower. npm installs / updates always seem to take forever. I get the difference between flat / nested dependencies, but still. That's been my experience as someone who rarely needs more than what bower provides.

[nwwells]

@miztroh, I totally agree with you.

[nwwells]

OK. I have a confession to make. I just did a huge npm land grab. I cloned all the elements currently in the catalog, converted the bower.json into something compatible with npm's package.json, and then published them. Ran into the aforementioned conflicts:

• google-analytics
• google-calendar
• google-feeds
• google-sheets
• paper-button
• paper-checkbox
• paper-ripple
• paper-slider
• paper-tabs

After seeing that some of those projects are just node utilities that probably won't sacrifice their nice real estate on the altar of polymer, I wondered if I could simply prepend all the package names with polymer-. Turns out none of those project names are taken!

Well, they are now.

So, I think the polymer- prefix is probably the best move. It namespaces, but doesn't have the negative side effects of scoping (search works... yay!). I'm sure that we can automate the generation of the package.json (... I just did), so I don't feel like that should be a huge concern.

Thoughts? I am, of course, willing to hand over any/all of these modules to the right people. Heck, I'll even delete them if that's what the community wants. I just didn't want to let any more of the names get into the wrong hands.

[oleersoy]

@oleersoy: this crops up with any component-first framework

@jokeyrhyme the first question is does it need to?

[jokeyrhyme]

@oleersoy we can avoid dependency version conflicts by never exposing a public API surface, and/or never using modules. I think we're already past this point though. :P

[robdodson]

Thank you @nwwells for this thoughtful followup.

One bit jumped out at me:

After you can get any polymer package on npm, then we can solve integrating with build systems, whether that's browserify, webpack, or whatever. If the polymer project governance (i.e. "You people") decide that browserify (or w/e) is a pain, or can't be supported in a general way, then great. We (the devs) can handle that on our own.

I wrote a thing a few weeks ago to integrate Polymer with browserify and figured I should put it out there in case anyone in the community finds it interesting. It's called spock-cli and it lets you use ES2015 or CommonJS modules inside of your Polymer elements. It is by no means a fully baked, production-ready thing, but it's fun to play around with the ideas :) @justinfagnani, @samccone, @addyosmani, and myself have been kicking around a plan to take some of the features of spock and roll them into a first-class build tool for Polymer. That work will start soon on GitHub so everyone can participate.

Finally, (totally off-topic for this issue) I wish there was a lot less "us" and "them". It seems really off-putting to me. I'm a member of the community, which means I'm part of the team. I'm one of those "other humans".

We totally agree and there's been a lot of discussion recently within the team to figure out how to fix this. Our plan for 2016 and beyond is to give more ownership and control back to the community. So when someone opens an issue, instead of letting it just sit there, we ask the creator to open a PR and offer to help them through the process. I think Sam and Addy have set a good example with Polymer Starter Kit, which is largely driven and maintained by community contributions at this point. We want that same level of community ownership for pretty much everything that falls under the Polymer org.

So yeah, big +1 to everything you said!

[chuckh]

@nwwells thanks for setting up npm polymer- elements. I tried to install few different polymer- elements using:

• npm i polymer-iron-icon
• npm i polymer-paper-input
• npm i polymer-paper-button
• npm i polymer-paper-toolbar

But on all of them getting the below errors: (using node v5.4.1 and npm v3.5.3)

npm ERR! git rev-list -n1 %5E1.0.0: fatal: ambiguous argument '%5E1.0.0': unknown revision or path not in the working tree.
npm ERR! git rev-list -n1 %5E1.0.0: Use '--' to separate paths from revisions, like this:
npm ERR! git rev-list -n1 %5E1.0.0: 'git <command> [<revision>...] -- [<file>...]'
...
npm ERR! Command failed: git rev-list -n1 %5E1.0.0
npm ERR! fatal: ambiguous argument '%5E1.0.0': unknown revision or path not in the working tree.
npm ERR! Use '--' to separate paths from revisions, like this:
npm ERR! 'git <command> [<revision>...] -- [<file>...]'

Has anyone been able to install any of these ok?

Doing npm i npm-polymer-elements worked fine.

[ChadKillingsworth]

I didn't know this discussion existed - I was watching #2578.

The Polymer project has continually felt like it caters to the least common developer at the expense of the advanced user. Reading this issue continues to reinforce that idea.

Publish to npm. Bower causes real heartache. Let me list the ways:

• Uses github as a CDN
• Requires built files to be committed back to the repo (yuck)
• Offers a "flat" dependency structure - without telling you of the hell that will ensue maintaining resolutions.
• Has been known to randomly corrupt downloads
• No good way to have an internal registry
• Has only 1 core dev that has no plans to address these issues

I will second the motion that you publish first, figure out the build story later. I can figure out my own build story - I already do. From my other thread:

Because Polymer is only distributed as an HTML import via bower, I'm having to run through a build tools gauntlet to convert it to a standard JS script: vulcanize for single import, crisper to factor out into separate script, custom rule to re-add license, etc.

I can offer you an easy migration path: write a custom bower resolver. It will allow your bower installs to at least work off the npm registry. I'm the author of the bower-sinopia-resolver because of this exact same problem. I'll even be willing to help.

[nwwells]

@chuckh I need to apologize! I had replied on Friday, but apparently the message didn't get through to github. Here's basically what I said:

Yeah, they won't work until we properly convert the bower.json files into npm package.json files. I think that's the next step, some sort of bower2npm translator. Hopefully that's not too difficult, and I've got kind of a mental start on it:

1. prepend polymer- to the name.
2. remove any "private" key, if there is one.
3. remove the "main" key, as it's relatively useless in this context (bower main and npm main simply mean different things
4. translate dependencies to npm dependencies rather than bower repo references.

That last, I think, is the reason why the current ones fail.

[chuckh]

@nwwells np :smile:. Your plan makes sense. Let me know once you have given it a shot and I will try testing it.

[justinfagnani]

We've started publishing packages to npm under the @polymer scope. Polymer core is here: https://www.npmjs.com/package/@polymer/polymer

I'll have the elements up tonight or tomorrow.

[justinfagnani]

Ok, Polymer and all the elements are up (except for paper-listbox for some reason). You can see the list here: https://www.npmjs.com/~polymer

You can install packages with npm i @polymer/paper-input etc., and use them in html like:

<!doctype html>
<html>
  <head>
    <link rel="import" href="node_modules/@polymer/paper-input/paper-input.html">
  </head>
  <body>
    <paper-input label="Testing"></paper-input>
  </body>
</html>

This works because all the Polymer-team packages are in the same scope. We'll need some polyserve and/or gulp goodness to make relative imports work across different scopes and unscoped packages.

[ericelliott]

I would suggest npm scripts rather than gulp. Not everybody wants to use gulp, but all npm users have npm. ;)

[justinfagnani]

Oh, and a quick note on versions.

I accidentally published @polymer/polymer with some bad dependencies, so I unpublished it, not knowing that I wouldn't be able to re-publish it with the same version. So that burned v1.2.4.

Then I decided to publish every package with a v0.0.1 so that I could rev packages quickly if the bower.json -> package.json translation had problems. @polymer/polymer had already been published though, so I set its version to 1.2.5-npm-test.1 so that we don't stomp on the 1.2.5 version. Once we try out a few more tests, push the package.json commits, and release Polymer 1.2.5 or 1.3.0, I'll republish all the elements with their real version.

I updated our repo management tool to generate package.json from bower.json, using bower.json as the source of truth, but I published with some simple shell commands. Soon I'll update the tool to tag a release in github and npm publish at the same time so that we can guarantee that we have the exact same versions available in bower and npm.

[justinfagnani]

@ericelliott users will be able to use whatever they want. Building files for loading by browsers won't be prescriptive, but we'll have some demos showing some of the myriad ways it could be done.

[jokeyrhyme]

Now that HTML Imports is basically dead (only natively implemented in Chrome and likely to be this way forever due to ES2015 modules having more vendor favour), I wonder if we could just bake a custom module resolver into the HTML Imports polyfill, and use the polyfill even in Chrome?

What if instead of

<link rel="import" href="node_modules/@polymer/paper-input/paper-input.html">

we used

<link rel="polymer-import" href="@polymer/paper-input">

and let our custom HTML Imports resolver figure out the right thing to do. This could check both node_modules and bower_components, it could check relative paths, anything that makes sense.

This could make life simpler for both npm and bower users.

[justinfagnani]

@jokeyrhyme HTML Imports are far from dead. They were discussed at the latest standards meeting, and now that <script type="module"> and JS module loading specs are progressing, there's movement on unifying the loaders.

Regardless, you don't want the browser checking multiple paths for a module like node does. The resolution of a module name or path should be done purely on the client.

[rictic]

Yeah, HTML Imports are quite compatible with ES Modules. They've had a low priority in the standards meetings so far mostly because they're super easy to polyfill and everyone's been waiting for ES Modules to get sufficiently hashed out. I believe they're on the docket for the next web components standards meeting.

[ericelliott]

@justinfagnani

@ericelliott users will be able to use whatever they want.

Great news. =) Thanks for your work on this. It's much appreciated! :+1:

[jokeyrhyme]

Regardless, you don't want the browser checking multiple paths for a module like node does. The resolution of a module name or path should be done purely on the client. -- @justinfagnani

Previously:

After Polymer:
bower -> usable project
npm + bower + build steps -> usable project -- @justinfagnani

I only suggested having client-side check multiple paths because you seem to value having the shortest path possible to "usable project", e.g. clone, npm install, open in browser

I would hope that nobody is deploying non-vulcanised Polymer projects in production, and I would want the production-mode resolver to short-circuit any guesswork. But performing multiple checks seemed like it would be okay for developer-mode.

In any case, it's great news that there is a unification effort behind the scenes. :D

[ChadKillingsworth]

This is awesome news!

[TimvdLippe]

Given the complexity of the task to publish all projects on NPM as well as the various arising problems to successfully complete the transition, would it maybe better to create a separate repository for the issue management of all problems? I have been keeping an eye on this thread and I think keeping it in just 1 thread makes it hard to keep a complete overview of the progress and accompanying issues. Moreover, in such a repository, a guide or usage manual can be created on how to use Polymer with just NPM. My 2 cents.

[justinfagnani]

@TimvdLippe at least at first, I think additional repos bring discoverability issues. We can open general npm issues on the main repo, any package specific ones on the respective package repo, and any tools we develop to help with npm will have their own repos as well.

I'm sure we're open to different organizations in the future if this doesn't work.

[nwwells]

So, obviously some decision was made against the polymer- naming. Shall I just delete those packages, then?

[justinfagnani]

I think that would be best. Thanks for your help and cooperation @nwwells !

As for the decision to use a scope, @polymer/ gives us the ability to add new packages using the prefixes we already have (paper-_, iron-_, gold-_, platinum-_, etc.) without the risk of future name conflicts. Prefixes only do that by convention, yet have the same path problems that scopes have. We're a little bt on the bleeding edge by using scopes, but I hope that npmjs.com scope support ramps up quickly. We're following issues like: https://github.com/npm/download-counts/issues/23

[justinfagnani]

I pushed a few new versions of the elements to fix some issues I had came across while making a demo.

The demo: @notwaldorf's awesome <emoji-selector> converted to use npm, can be seen here: https://github.com/notwaldorf/emoji-selector/pull/5

I preserved the ability to use the package from Bower, since there's no hard-coding of the components directory, and matched the layout of bower_components/ in browser_components/. To serve the demo I used a patched version of polyserve that allowed me to set the component directory to something other than bower_components/, in this case browser_modules/. I'll submit that patch asap.

One general class of problems that will be common are packages that are laid out differently in Bower vs npm, which I fixed case-by-case.

Note, that this is only one way to use npm packages. Again, this is not prescriptive, just a demo.

If anyone here wants to try converting other projects it will be very helpful in finding holes in our packages and related packages.

[nwwells]

@justinfagnani done.

[justinfagnani]

Thanks @nwwells!

[justinfagnani]

polyserve 0.6.0 is now published, with the -c and -n options to specify the component dir and package name which were previously only read from bower.json. You can run the npm version of <emoji-selector> with polyserve -c browser_modules -n emoji-selector. Then navigate to http://localhost:8080/components/emoji-selector/demo/index.html

To load the documentation you currently have to run both npm and bower install because the npm version of hydrolysis doesn't include all the files needed for the browser.

[abdonrd]

Nice work @justinfagnani!

[stramel]

:+1:

[MeTaNoV]

+1

[leodido]

+1

[jordanaustin]

When will you be publishing v1.3.1 to npm? I noticed the package.json version was bumped but still seeing v1.2.x on npm.

[addyosmani]

@justinfagnani is Tedium currently setup to publish sub-projects to npm or does this require a manual publish to address the above request? Would be great if we could keep this automated so versions stay in sync everywhere.

[ChadKillingsworth]

ping - 1.2.5-npm-test.2 is still the latest version on npm.

[jordanaustin]

I can see the package.json file is being kept up-to-date but you aren't publishing the updates to npm. Bower has 1.4.0 but npm only has 1.2.5-test.2.

Can you publish the same versions on both bower and npm, we need to keep these in sync.

[robdodson]

Yep, just spoke with @tjsavage who said we'll add it to our launch checklist

[schippie]

@robdodson Is there any time indication for when you expect the new version to be published to NPM? Or should it be done shortly?

[tjsavage]

ASAP - @justinfagnani WDYT?

[jordanaustin]

@tjsavage @justinfagnani since you've already taken the steps to get it on npm it seems like keeping npm in sync with polymer releases should be pretty trivial. As soon as you made these packages available on npm our company (and I'm sure many others) moved to installing polymer from npm, however we've been stuck on v1.2.x due to no updates on the npm package for 2 months.

Do you foresee this being an issue moving forward or is the plan to maintaining the same versions across bower and npm in the near future?

Thanks for your attention on this!

[justinfagnani]

Unfortunately nothing's trivial across 150 repos and a dozen developers. Since we use bower, our release process consists bumping version in one file and making a release in Github. Adding npm means we need to keep package metadata in sync and perform two different release steps. We're writing a tool to automate this, along with test integration, so that they don't go out of sync in the future.

The current set of packages was pushed mostly to see if things would work and find issues in related packages. When we're ready to actually support the packages fully going forward, I think we'll make a loud announcement about it. I'll work on updating the current asap, hopefully today, and keep this issue update on the progress of our release tool.

[jordanaustin]

@justinfagnani I'm sorry, I guess trivial was the wrong word. I appreciate your attention to the needs of developers trying to use Polymer.

Thanks for your support!

[jordanaustin]

@justinfagnani @tjsavage Any updates you can share?

[jokeyrhyme]

I've noticed recently that scoped packages show up in npm search results now (as long as they are public). So that should help with the visibility of "polymer"-scoped packages.

[robdodson]

@jokeyrhyme that's awesome! thanks for the heads up. I just made sure the team knew about this. As a bit of an update, we're actively working on this. Like peeps are literally at desks typing the codez to see if we can make it all work. Hope to have some more progress in the coming weeks.

[justinfagnani]

@jokeyrhyme thanks for the info. It's not working for me, but maybe there's a staged rollout. Exciting. As @robdodson mentions, we have a new member of the tools team working on this right now.

Our first step is to make a release tool that tests our elements under bower and npm installs, and then published to both, so that we keep them in sync. Given our previous bower-centric, and distributed, release process, the npm packages would have likely had spotty support.

Since our elements often have many transitive dependencies, there's an implication here that to test them we need a tool to flatten dependencies - which might also have to take into account different package names between bower and npm. This could hold things up a little, but hopefully not. We'll have a repo soon, and I'll ping this issue.

[timblack1]

Would this fix Polymer's problem of resolving nested dependencies at the source?

This is my recommendation for the web components spec, but I'd like to post it here to see if Polymer folks think it would work: Tie the browser's element/component registry deduplication to HTML import deduplication. In other words, make the browser's registry recognize that the x-foo element/component loaded from URL A is not the same as the x-foo element/component loaded from URL B, and make each element/component available only to the scope of the file into which it was imported, and the scopes of that parent file's child elements, such that, for a child scope, elements imported into that child scope override elements of the same name inherited from its parent's scope. That way version numbers are not needed in component names (like x-foo:1.2.3). Then make HTML references to elements/components resolve to their containing file's explicitly HTML-imported (and (npm-)nested immediate) dependencies first (e.g., node_modules/containing-element/node_modules/x-foo/x-foo.html), and (if the former was not explicitly imported) second to the top-level _first-registered_ dependency of the same name (e.g., node_modules/x-foo/x-foo.html).

Note: Edited to rename "top-level" to "first-registered," and to describe element scoping.

[ansarizafar]

Any update?

[HIRANO-Satoshi]

+1

We are looking forward to using npm packages. We want to use Polymer with Webpack and npm.

[oleersoy]

@timblack1 I'm hoping your suggestion is as brilliant as it seems ... is this already implemented? So basically the same module resolution algorithm that node uses on the server side ... on the client side ...?

Any chance this could get fleshed out any more with a simple example of how it would work hypothetically?

[timblack1]

1. @oleersoy, to answer your first question, I'm pretty sure this is not yet implemented.

2. To answer your second question, note https://github.com/Polymer/polymer/issues/326#issuecomment-178384959 by @justinfagnani above. At least until HTTP2 fully arrives, HTML imports should avoid multiple requests for one file in order to save on network bandwidth and latency. Node attempts to import from every containing folder and a number of other paths (see https://nodejs.org/api/modules.html#modules_addenda_package_manager_tips), so no, I'm not proposing HTML imports use the same algorithm as Node. My proposal is much simpler: HTML imports should try to load a file from ONLY ONE of the following two locations:

   1) the HTML import's containing file's explicitly HTML-imported (and (npm-)nested immediate) dependencies first (e.g., node_modules/containing-element/node_modules/x-foo/x-foo.html), and

   2) (if the former was not explicitly imported) second to the top-level _first-registered_ dependency of the same name (e.g., node_modules/x-foo/x-foo.html). By "first-registered" I mean the browser should simply use the element of the same name which was first entered in the browser's custom elements registry. So far as I understand, this is the way HTML imports work now. This requires the first-registered dependency to be explicitly imported before the current file is loaded.

   So, to state this somewhat more simply, HTML imports already resolve location 2) above; my proposal is for browsers to resolve location 1) first.

   More specifically, this proposal requires browsers, when they see some HTML's reference to <x-foo>, to check whether the current HTML file explicitly imports an x-foo component. If so, use it; if not, use the first-registered x-foo component.

   This also requires browsers' custom element/component registry to store two more pieces of data along with the element's name: the URL from which the component was loaded, and the order in which the components were registered. If the registry's current data format is something like this:

   registry: [
   'x-foo': {
     name:  'x-foo',
     code:  '...'
   }
   ]
   

   its new data format would need to be like this:

   registry: [
   'x-foo': [
     {
       name:  'x-foo',
       code:  '...',
       url:  'a/b/c',
       registry_order:  1
     },
     {
       name:  'x-foo',
       code:  '...',
       url:  'x/y/z',
       registry_order:  2
     }
   ]
   ]
   

   This proposal does what @justinfagnani stated is best, "The resolution of a module name or path should be done purely on the client."

3. To answer your third question, here are several examples of how this could work:

   Load a 3rd party component's nested dependency
   If
   node_modules/containing-element/containing-element.html
   contains

   <link rel="import" href="node_modules/x-foo/x-foo.html">
   <x-foo></x-foo>
   

   then the browser loads
   node_modules/containing-element/node_modules/x-foo/x-foo.html.

   Load a 3rd party component's previously-registered dependency
   If
   node_modules/containing-element/containing-element.html
   contains only

   <x-foo></x-foo>
   

   (note there is no explicit HTML import!) then the browser loads whatever x-foo component was first registered (because it was already explicitly imported by another file).

   Load a custom component's nested dependency
   If
   elements/containing-element/containing-element.html
   contains

   <link rel="import" href="node_modules/x-foo/x-foo.html">
   <x-foo></x-foo>
   

   then the browser loads
   elements/containing-element/node_modules/x-foo/x-foo.html.

   Load a custom component's previously-registered dependency
   If
   elements/containing-element/containing-element.html
   contains only

   <x-foo></x-foo>
   

   (note there is no explicit HTML import!) then the browser loads whatever x-foo component was first registered (because it was already explicitly imported by another file).

[oleersoy]

Sweet - Seems like it should be pretty straightforward to build vulcanize tooling for that as well.

[justinfagnani]

I just want to point out that HTML imports and JavaScript modules do no name resolution at all, they simply load from URLs. This isn't going to change any time soon.

When we have more to say on npm support (soon!), it will be within the constraints of the current standards so that it can be used now, and with native implementations.

We are working on the new release tool for our team that will include publishing to npm, so soon we'll have up-to-date packages on npm. Consuming them will remain an exercise for the reader for the time being, and any patterns that people figure out that work will be really, really appreciated.

Our plan at the moment is to have a tool that pulls (a subset of) the top-level of node_modules and any scopes and puts them into a web_packages/ folder that can be used by URL-based loaders. We'll probably have to come up with some additional metadata to put in package.json and/or bower.json to iron out differences between some npm and Bower packages.

[timblack1]

We are working on the new release tool for our team that will include publishing to npm, so soon we'll have up-to-date packages on npm. Consuming them will remain an exercise for the reader for the time being, and any patterns that people figure out that work will be really, really appreciated.

I wonder if it's possible to implement my proposal (above) in a monkey-patch to the HTML imports polyfill.

[jokeyrhyme]

@timblack1 take a look at React's version scheme: https://facebook.github.io/react/blog/2016/02/19/new-versioning-scheme.html

They avoid version complexity by just having a single version of each library and component in an app at a time. There should never be 2 versions of the same component. Their deprecation-to-removal window is such that a library / component can straddle at least 2 versions of React itself.

I'd like to avoid making WebComponent registration and resolution any more complex than it already is. Assuming HTTP Cache headers, browsers will already only download 1 component just 1 time.

[oleersoy]

@jokeyrhyme if you insist on enforcing such a policy you will make impossible for us to create and combine components in the wild.

Web component registration and resolution could be really simple, just like Tim Black is suggesting. We really need something like 'Project Jigsaw (Java) / OSGi' in the browser such that we can build applications without having to worry about transitive dependencies conflicting.

Ideally all the components are unique across the entire dependency graph, but that should be a secondary consideration. Let devs first build, and then try to clean up the graph post assembly.

Also it would be great if the Factory for instantiating and rendering components is pluggable (Maybe it is...) so that we can experiment with different approaches to instantiating the app.

[timblack1]

@jokeyrhyme, I agree my proposal makes web component registration more complex, as it would require changing from having one global registry of custom components to having a registry which respects nested scopes. However, it appears to me that Polymer already provides nested scopes for CSS and JavaScript (as do ES2016 modules), so it seems quite reasonable to me that custom components should have nested scopes, too.

Why should it be the web components spec (the browser!) rather than the developer (e.g., React's conventions) who decides that "There should never be 2 versions of the same component"?

[jokeyrhyme]

@timblack1 @oleersoy I suppose what we really have here is one component named "myComponent", and incompatible versions 1.0 and 2.0 of it. If what we've loaded into our app is really something like "[email protected]" and "[email protected]", then technically the framework and browser are looking at 2 completely different components, even though the human app developer has a different perspective.

I think we already have everything we need to support what it is you are asking for, without having something like OSGi in the browser.

Also, npm 3+ nests modules when there are conflicts. There might be a way to use this to our advantage during the build process. /shrug

[timblack1]

@jokeyrhyme, https://github.com/Polymer/polymer/issues/326#issuecomment-136746986 says "The page itself will throw an error saying something like 'attempt to register "x-foo" but "x-foo" already exists'."

[oleersoy]

We really have to think about this:

How many components do we think there will be in the wild that devs are going to want to assemble from?

Right now on NPM there are over 250K building blocks and 1127739058 weekly package downloads. Can you imagine what would happen if every time someone wanted to build something they got a bunch of version conflict errors that had to be cleaned up.

So we can say "No problem we will just limit the ecosystem to sets that all have guaranteed flat dependency graphs .... But exactly how is that done without a North Korea like approach?

Also an application can have two different major versions of the same component. The app can be composed of module 1 and module 2. Module 1 depends on myComponent version 1 and module 2 depends on myComponent version 2. The scope of myComponent would be limited to the module that contains it.

[robdodson]

I don't think we'll be able to rewrite how the HTML Parser handles Custom Elements (at least not anytime soon). We still need other vendors to ship Custom Elements v1 so we probably can't touch the spec for a while.

Having said that, one option suggested by Domenic Denicola, would be to _not_ have the HTMLImport (or ES Module if that's how you're loading your definition) call registerElement. Instead that would be up to the developer. Then you'd have total control to import xFoov1 and xFoov2 as classes and call document.registerElement('x-foo-v1', xFoov1), for example.

Might be interesting for folks in the community to experiment with this approach and see if they like it ʕ •ᴥ•ʔ

[jokeyrhyme]

@oleersoy @timblack1 do we have any of these numbers?

• number of large / complex WebComponents projects?
• average and maximum number of components per project?
• number of projects where it is preferable to have 2 versions of myComponent instead of just updating the whole app to only use myComponent v2 ?

I would avoid, with all my might, having multiple versions of jQuery, or multiple versions of Angular, or multiple versions of anything like that in the same page. Why would I not apply this same approach to individual components and libraries? Just use the latest version that plays nice with everything else?

[oleersoy]

@jokeyrhyme naturally we all want to avoid having duplicates of components. It's cleaner and more efficient.

But we need something that will allow us to handle this as a secondary requirement. Let devs look at the graph themselves and clean it up after attempting a prototype. The ecosystem will grow much more rapidly without the boot lock and developers will love Polymer a lot more.

[Splaktar]

I can imagine many different business cases where updating a component in one module of the app is needed, but where it is not desirable to update that component in other modules of the app. This is especially true for large business applications (which may not be the sweet spot for Polymer yet, but that does seem to be a goal). This could be due to cost, schedule, politics, and many other reasons.

[timblack1]

@jokeyrhyme, I don't have any of those numbers. It would appear those numbers are currently limited by browsers' inability to have multiple versions of the same components in one page (which is the point in question), so I think a different metric would be more suitable to demonstrate your point. Perhaps a metric like "number of large / complex web components apps vs. number of large / complex web apps which permit multiple versions of the same functional units" would be more revealing.

Why would I not apply this same approach to individual components and libraries?

Because module scopes handle application complexity better than does a global namespace, and web components are intended to provide modularity. This is also the reason for NPM's nested, rather than flat, dependencies.

Interestingly, https://www.polymer-project.org/1.0/ states Polymer is

Fully interoperable. Polymer-powered elements are based on standard Web Components APIs, so they work seamlessly with the browser's built-in elements and other Web Components.

I have no complaints (I drank the Kool-Aid and love Polymer!), but given the reality of dependency conflicts, which are due to the fact browsers are unable to load more than one custom element of the same element name, this statement seems not quite true. Because part of the intent of web components, so far as I understand, is to permit you to use other people's components as drop-in functionality like we use native HTML elements, I think what we've realized here is that the spec doesn't yet fully implement the web components vision. I trust future versions of the spec will be even better than what we have now.

[oleersoy]

I think a good 'hardening' test for Polymer would be to walk through the requirements needed to scale the Chrome Dev Editor up to an IDE like Eclipse, or Atom, where there is an Ecosystem of plugins.

[abdonrd]

@oleersoy Chrome Dev Editor is deprecated: https://github.com/GoogleChrome/chromedeveditor

[oleersoy]

Is it because it was realized that it can't be scaled with Polymer? :)

[robdodson]

@oleersoy It was a 20% project by members of the Dart team. They've since switched to other projects and their team decided that it would be better to just sunset the project.

If you'd like to see examples of Polymer at scale take a look at Google Play Music or YouTube Gaming. Both built in Polymer.

This discussion seems to have diverged a fair bit from the original issue of publishing packages to npm. Please keep the comments on topic.

[oleersoy]

@robdodson the intent of the original comment was to was to gain some insight into how something like Chrome Dev Editor could be scaled with a plugin eco system around it.

Because many of us have this feeling that it simply won't work and the reasons are the ones that were being cited for not putting Polymer dependencies on NPM in the first place. I won't rehash the whole thing, but it is very much on topic. The reason we want it on NPM is so that we can start using it with the rest of the NPM eco system to build awesome narly things. If we're not going to be able to do that then the value of having the packages on NPM is very much marginalized.

Are you saying that if we tried to build something like Eclipse or Atom with Polymer as is right now it would be straightforward to do so or just acknowledging that it would be pretty much impossible?

I don't think Google Play Music or Youtube Gaming qualify because they don't assemble various plugins into the same runtime that can be built by many 3rd parties AFAIK...?

Polymer is a brilliant project, but if all we are going to be able to do in the near term is tweet or search for songs, then that's a darn shame.

[AndreasGalster]

@justinfagnani Will your npm version of the Polymer Elements use the same npm scope and package names (excluding the ones still to add) as on npm right now with the experimental items that are roughly 5 months out of date? We have built quite a few elements with those references and are basically just sitting, waiting, wishing for your npm release to happen (doesn't matter if experimental/beta!) so that we can release and open source our elements on github. We're just waiting to see how the folder structure will look like so we can set up our demo files properly.

[justinfagnani]

@AndreasGalster Yes, we'll use the @polymer scope. However, we're going to make sure that components can reference dependencies the same regardless of whether they're installed via npm or Bower. This means that dependencies are still going to be imported with ../other-package/element.html style URLs. For Polymer and Polymer elements, the canonical URL _won't_ include the @polymer scope - they will stay the same as they are now.

I think it's a bit unfortunate that you're waiting for us to publish production-ready packages on npm. That leaves the significant number of Bower users out in the cold, when your elements could almost definitely be useful to people now.

We hope that when we have an easy-to-use release tool that tests and publishes both npm and Bower packages of a project, that third-party projects will use that and publish working packages to both systems. Part of the reason we're not rushing to npm is exactly to not fragment the ecosystem too much. It will be inevitable that some components will only be available via npm, and some only via Bower, and then common dependencies are in danger of being duplicated, but I'd certainly like to discourage that, by encouraging maintainers to publish the same module to both npm and Bower during some kind of transition period. That means it should be fine to publish to Bower now.

[AndreasGalster]

Will we be able to reference components (especially in the component folder for demos) like this?

require('@polymer/paper-button/paper-button.html');

That would be nice. I'd say import/export and/or require are currently the standard, referencing node source files this way is common and it is also less verbose than html imports.

We're waiting for npm because meteor doesn't support bower unfortunately. Also, we're not 100% sure if we can use require (since our components use require), we just haven't found time to investigate that. The problem with bower right now is that it's simply a dead ecosystem. We're releasing new components, so releasing them to bower and going through even the slightest hassle for this won't make sense (we're busy) and we're rather just release them on npm, knowing that most people will use npm anyway since it's the defacto standard now.

We will look into supporting bower once your npm support is out.

[justinfagnani]

@AndreasGalster no, there won't be any changes from the element side, you'll still import Polymer and elements via URL:

   <link rel="import" href="../polymer/polymer.html">
   <link rel="import" href="../paper-button/paper-button.html">

Like I said, the scope name will not appear in the canonical URL. We're only using npm scopes to deal with name squatting within npm.

For use from JavaScript code, we could offer a function like this:

export function importHtml(url) {
  return new Promise((resolve, reject) => {
    let link = document.createElement('link');
    link.setAttribute('rel', 'import');
    link.setAttribute('href', url);
    link.addEventListener('load', (e) = resolve(link.import));
    link.addEventListener('error', (e) = reject(e));
    document.head.appendChild(link);
  });
}

Which you would use something like:

import {importHtml} from '../webcomponentsjs/import-html.js';

importHtml('../paper-button/paper-button.html').then((document) => {
  console.assert(document.createElement('paper-button').is === 'paper-button');
});

[AndreasGalster]

Does that mean the demo pages or polyserve will have some support for babel since you're mentioning import here? Or was that just an example you came up with on the fly so nothing's decided yet?

[justinfagnani]

@AndreasGalster I'm not sure I understand the connection to Babel

[AndreasGalster]

You're proposing an export/import above, so I would expect babel support since there's great browser support for modules yet. Besides, I would really expect ES6/next support in Polymer components or rather demo pages in general but we're getting off topic with that part I guess. I was just curious if you have a proposal for dealing with ES6 since you mentioned import/export and how we would preview that on a demo page if a browser doesn't support import/export.

[dandv]

TL;DR - what's wrong on NPMJS with https://www.npmjs.com/package/Polymer that it shows there's no README but on the other hand shows the same GitHub stats as the legit @Polymer? Did we lose the namespace?

CC @k-paxian.

[k-paxian]

Dan,

It looks like a plain bull shit, since
those packages are really different
https://www.npmjs.com/package/Polymer
and
https://www.npmjs.com/package/polymer
and
https://www.npmjs.com/package/@polymer/polymer

The reason I've published https://www.npmjs.com/package/Polymer
because I cannot fetch packages behind my company firewall which are
pointing to github.com,
we have policy to reject all queries to github.com, but we need a polymer
:).

And this all goes mad when "@polymer" dependencies are fetched from
npmjs.com, npm package manager is trying to access github.com
and our build fails. So for coroporate users this tight dependency on
github.com is a really annoying and very bad thing.
We don't need any relations to github.com, since we are using npmjs.com
repository solely, why you should make everything so hard to consume?
Same goes for "@angular", we simply can't fetch it and forced to re-publish
all the stuff manually under plain package names, without any namespaces
implying dependency on github.com.

On Tue, Aug 16, 2016 at 9:48 PM, Dan Dascalescu [email protected]
wrote:

TL;DR - what's wrong on NPMJS with https://www.npmjs.com/package/Polymer
that is shows there's no README but on the other hand shows the same GitHub
stats as the legit @Polymer
https://www.npmjs.com/package/@polymer/polymer? Did we lose the
namespace?

CC @k-paxian https://github.com/k-paxian.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Polymer/polymer/issues/326#issuecomment-240216349,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARO94gxx2TeqgMPyB96vz2M0rHqYiQHKks5qghQcgaJpZM4BH6Sc
.

Alexander Mazuruk

[mgol]

@k-paxian The Polymer package displays stats from the polymer one because npm now doesn't allow to publish new packages under the name that includes upper-case letters and they didn't deem it important enough to fix the stats for those packages that registered such a name when it was still allowed.

without any namespaces implying dependency on github.com

npm package namespaces have absolutely nothing in common with GitHub. Similarly, the @polymer/polymer package doesn't have any dependency pointing to GitHub, everything is on npm. So I'm not sure where you got that from.

[k-paxian]

@mgol Really? Please stop theorizing and take it yourself, deny access to github.com on your proxy server and try to install anything with "@polymer", "@angular" namespaces via npm. Also we are behind https://www.jfrog.com/artifactory/ system.

I'm able to fetch this https://www.npmjs.com/package/ng2rc5
but completely unable to fetch anything wrapped with the "@angular" namespace through Artifactory system. So possible this is an Artifactory issue.

[jokeyrhyme]

@k-paxian which version of NPM are you using? You will need NPM v3+ to be able to work with scoped packages. It is possible that your NPM proxy / cache system is not compatible with NPM v3+ ?

[k-paxian]

@jokeyrhyme Yes, this might be the case, since we are forced to use node 4.2.2 and npm 2.14.7, and unfortunately we have no rights or access to all environments to upgrade those.

[mgol]

That explains the problem. You may read more about scoped packages at https://docs.npmjs.com/misc/scope.

[mgol]

Actually, npm added supports for scoped packages in version 2.0.0: http://blog.npmjs.org/post/98131109725/npm200. So I'd expect the problem lies in Artifactory, not the Node/npm version used.

[k-paxian]

@mgol Thanks for the info, looks like this is it, anyway, we cannot upgrade Artifactory just right now, since it's a long burocracy procedure which can take dozens of months to resolve. That's the corporate side of the technology :)

[oleersoy]

@timblack1 @robdodson I started looking into your ideas on dealing with transitive NPM dependencies and posted a SO question WRT to the CSS part of it (Hopefully I don't get blown up due to it being to broad):
http://stackoverflow.com/questions/39086720/applying-css-to-dynamically-named-polymer-elements

Should we perhaps open a separate issue for this and move that part of the conversation over?

[robdodson]

I think the pattern would be pretty tough to pull off the more I think about it. If I have component x-foo, it would mean any usage of <x-foo> in HTML, x-foo in CSS, or querySelector('x-foo') in JavaScript would have to be changed to my new element name.

I honestly don't know if I'd personally trust a tool to run across all of my code and make such changes. We're currently exploring an npm solution that would prompt dependency resolution (similar to what bower does today) and my hunch is that's the direction we'll head in and the one that will have the least amount of issues for folks.

[oleersoy]

It seems like it would be nice for developers to have both the tool that helps them with dependency management and cleaning up the graph to a single set of dependencies and the ability to rapidly prototype using dependencies that are found on NPM (Both Polymer and other 3rd party components).

I see what you are saying WRT x-foo in HTML, CSS, and Javascript, but it also seems like this may end up being a complete non issue, since dynamic element naming would only be triggered for transitive dependencies.

In other words client code would not ever and should not ever try to deal with element x-foo-v143 since this element is an implementation detail that is encapsulated in another component.

For example if x-foo has a shared-button v1 and y-foo has a shared-button v2, why force developers to redesign one of the two, before continuing to prototype if the shared-button implementation works fine WRT both modules?

In this case the Polymer component factory could just rename the shared-button implementation to shared-button-v2 and let the developer know that it did that.

So in summary:
For querySelector(shared-button) I don't think that's an issue because shared-button-v2 is part of the y-foo module and is an encapsulated implementation detail. I'm not sure exactly how the polyfill works, but it could be that renaming shared-button to shared-button-v2 will work out to become a pseudo shadow dom in the sense that querySelector(shared-button) will now select only light dom shared-button instances ... the behavior we want ...

CSS
True we can't select shared-button-v2 via a selector but I don't think we should be doing that anyways. Module styling should be done via variables so instead of directly styling shared-button-v2 we would use style variables like y-foo-shared-button-border-radius and x-foo-shared-button-border-radius.

Developer would still only use <x-foo> in their markup (And never <x-foo-v2> - ... strictly managed by the polymer factory.

I totally understand that Google wants to keep the core polymer team focused on tasks are low hanging fruit for it's products in the near term, but if we could have a separate issue for exploring whether this might be a complete non brainer then we may all end up seeing a great deal of benefit in the near future, rather than waiting maybe ... 8 years before all browsers can work with transitive conflicts for web components ....

Thoughts?

[robdodson]

You're free to open another issue if you'd prefer to continue the discussion over there. Presently our focus is on flattening the dependency tree so we won't have resources to dedicate to working on a new tool but if you want a space to kick around ideas that's totally fine.

[oleersoy]

Cool - and thanks - I just opened the issue now (Linked above).

I think this could work out really great with:

• A flat dependency tree for production apps
• An extended version of polymer (Community built if we like the architecture in theory) that can be used to prototype with 3rd party NPM dependencies
• A linter that supports cleaning up the graph and adding the results to a flattened ... repository... set of components ...

[oleersoy]

In the process of trying to figure out the what my ideal workflow is for Polymer WRT NPM I came across jspm which wraps both github and npm.

So if a package.json is added to the github repositories, that might be all that is required, along with JSPM for us to be able to have a dependency management solution that is probably better than just having the dependencies on NPM ...since it produces a flat multi versioned repository of all dependencies (CSS, Javascript, etc. - both transitive and direct) for the project. Essentially it flattens the NPM dependency graph.

Here's a TypeScript, Polymer, SystemJS article that demos the approach.

I found this article Modularizing client side dependencies with JSPM quite good in case anyone wants to examine this further.

[oleersoy]

Steps to publish packages for JSPM:
http://jspm.io/docs/publishing-packages.html#writing-a-library-or-application-for-usage-just-with-jspm

[FluorescentHallucinogen]

Will Polymer 2.0 be published on NPM when it is released? At least the library itself, not all elements made by the Polymer team.

All necessary polyfills are available on NPM.

[FluorescentHallucinogen]

@justinfagnani, could you please explain one moment from your talk at Polymer Summit 2016?

Initially Yarn supported multiple package formats and ecosystems (both NPM and Bower), but later Yarn decided to drop Bower support.

Since Polymer packages will be published on NPM, will it be possible to install and use them using only NPM without Yarn installed?

[jokeyrhyme]

@FluorescentHallucinogen NPM is 2 things: a package registry, and a CLI client for that registry. And Yarn is an alternative CLI client for the same NPM package registry. Anything published to the NPM registry can be installed using either the NPM client or Yarn.

[FluorescentHallucinogen]

Anything published to the NPM registry can be installed using either the NPM client or Yarn.

In that case, for what Polymer need Yarn at all (packages will be published on NPM registry and can be installed using NPM client)? How Yarn helps Polymer migrate from Bower to NPM?

[TimvdLippe]

@FluorescentHallucinogen Yarn has an option to install dependencies flat. E.g. the user must resolve version conflicts. This is how Bower works too and is required for custom elements as only 1 definition of an element is allowed.

[FluorescentHallucinogen]

@TimvdLippe

Yarn has an option to install dependencies flat.

NPM3 can also install dependencies in a flat way (see https://docs.npmjs.com/how-npm-works/npm3). What the difference between NPM3 and Yarn flat installation ways?

[TimvdLippe]

As pointed out in the docs you linked: NPM tries to do flat installation.
When it encounters a version conflict it will install nested again. You
need a true flat structure for custom elements and Yarn does support this.
NPM simply does not (yet).

On Sun, 22 Jan 2017, 12:55 Alexey Rodionov, [e-mail]
wrote:

@TimvdLippe https://github.com/TimvdLippe

Yarn has an option to install dependencies flat.

NPM3 can also install dependencies in a flat way (see
https://docs.npmjs.com/how-npm-works/npm3). What the difference between
NPM3 and Yarn flat installation ways?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Polymer/polymer/issues/326#issuecomment-274326485,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFrDb4X3nke7ExfnS9QLb8iuWWVpwmbUks5rU0PDgaJpZM4BH6Sc
.

[FluorescentHallucinogen]

@TimvdLippe Does this mean that users can not simply use NPM CLI and forced to use Yarn to install Polymer packages from NPM registry? That's what I asked initially.

Could you also answer another my question please?

[TimvdLippe]

@FluorescentHallucinogen I do not know about what will be published and what won't, I am not a member of the Polymer team :smile:

I assume that usage of Yarn is required to make use of the NPM registry. If I recall correctly, the plan is to switch off from Bower and move to Yarn.

[WoodyWoodsta]

That wouldn't make sense. AFAIK, Yarn is intended as a drop-in replacement for npm. A Yarn-only workflow should not be forced upon the developer and they cannot be used side by side (as is the case with Bower).

[TimvdLippe]

they cannot be used side by side

I am able to use both NPM and Yarn in my workflow, so I do not think it will be a problem.

That aside, let's wait till the Polymer team has fleshed out a full solution so we can learn the details, instead of trying to predict what will happen.

[WoodyWoodsta]

I am able to use both NPM and Yarn in my workflow

My apologies!

let's wait till the Polymer team has fleshed out a full solution

👍

[ChadKillingsworth]

Anything published to the npm registry should be at least installable with the npm cli. However, you should not expect to be able to utilize the whole ecosystem with the npm cli unless you develop some custom tooling for your project (to overcome npm's intrinsic shortcomings).

Yarn is also not a drop-in replacement for npm. In many cases it can indeed work with no modifications, but there are also quite a few edge cases where it doesn't.

Having not yet personally used the flat structure, I'm unsure yet how build dependencies can be installed in the standard structure and front-end dependencies can be forced flat. That is my single biggest question on how using yarn will work for standard polymer projects.

[justinfagnani]

@chadkillingsworth I think that a combo back-end + front-end project should have two separate pachake.json files, because the dependency graphs are different. This will allow a flat installation for the frontend and a nested installation for the back end.

[mgol]

@WoodyWoodsta

I assume that usage of Yarn is required to make use of the NPM registry. If I recall correctly, the plan is to switch off from Bower and move to Yarn.

That wouldn't make sense. AFAIK, Yarn is intended as a drop-in replacement for npm.

The fact that Yarn is intended as a drop-in replacement for npm only means that in most cases if you use npm you can switch to Yarn; the implication goes in one direction only. There are use cases satisfied by Yarn that are not possible in npm, like the bower-style enforced flat dependency hierarchy. There is no contradiction here.

[WoodyWoodsta]

@mgol Understood, I definitely think I worded it incorrectly. A few places in the docs indicated simply running Yarn in an npm project with high chance of no issues (which, for the record, was not the case for most of my projects :laughing: ).

The greater point of mine was that I don't think that the dev should be forced to use one of either npm or yarn when _both work for the same registry_. You're making an assumption about the project, application structure and workflow of the developer. For example, _the frontend_ of a project of mine has both a package.json and a bower.json. Dependencies in the package.json are installed using Yarn and consumed by rollup to generate bundles. Dependencies in bower.json are installed using bower and the output directory made available to the server. If bower is removed from the equation and replaced with Yarn, luckily I won't have to change the tool, but I'm forced to install dependencies with yarn install --flat which would not satisfy my rollup portion of the project.

Two solutions could be: 1) have two directories each with a different package.json, per _frontend_ project, or 2) provide another tool which is able to consume polymer dependencies from a nested hierarchy and produce a flat structure which can be served (a bit convoluted IMO, but just putting it out there).

[justinfagnani]

@WoodyWoodsta but we very intentionally _are_ making an assumption - or a requirement - of the developer workflow, and that is that Polymer packages are installed guaranteed flat. Nesting will absolutely break the installation. We aren't forcing yarn, we're forcing flat. If npm5 supports flat installations, then it'll work fine.

Right now it sounds like your setup works because the assumption is that your package.json dependencies are exclusively back-end and your bower.json dependencies are exclusively front-end. You have segregated your two environments by using two packages management systems. In the future when both front-end and back-end are described in a package.json file you'll simply have to continue to maintain two sets of dependencies, but by having two package.json files. I'm sure this is a common enough pattern already with projects that contain both front and back-end code.

[timoxley]

Note that yarn can install dependencies flat, but I don't believe it can be selective about it. Yarn is only a solution if users are willing to install all their other dependencies flat, which is a pretty heavy imposition and may be impossible for some applications. To get around this a user would have to create and manage a package.json specifically for polymer dependencies. This may be in addition to a package.json for other frontend dependencies which don't have this limitation.

[WoodyWoodsta]

@justinfagnani

Right now it sounds like your setup works because the assumption is that your package.json dependencies are exclusively back-end and your bower.json dependencies are exclusively front-end.

I mentioned nothing of the backend :smile:

@timoxley shares my train of thought.

[justinfagnani]

@timoxley We have constraints that impose flatness on us:

1. Only one definition of a tag can exist in a page. This means we must have absolutely no duplication of custom elements defining packages.
2. HTML import and JS modules only work by importing other modules via URL, this means that one module has to know exactly where a dependency module lives. Using relative URLs that assume all modules are siblings is the most direct and simplest solution. It's worked in HTML imports for us for quite a while now. Anyone who wants to use native JS modules will soon deal with this same issue.

Also, given the JS bloat problems we're seeing all over the web, it's probably just good practice to flatten dependencies. From what I've seen even with very complex node applications like the Polymer CLI or even Karma, applications generally continue to work and pass tests when flattened. Many semver-major changes are not actually breaking for most clients.

@WoodyWoodsta sorry, I assumed backend with the package.json. Still, the situation wouldn't change - one set of dependencies is flat, the other isn't. It just that you would use one package repository instead of two.

[timoxley]

@justinfagnani I think it's unreasonable to suggest teams entirely change how they manage dependencies just so they can use your library, especially if this change risks incompatibility with the rest of the ecosystem.

[justinfagnani]

We don't have a lot of choice in the matter. We cannot allow nested installations, the browser will throw an error.

[jokeyrhyme]

It's not as though nested resources are scattered to oblivion, or impossible to locate. By scanning package.json (and those of dependencies) it should be possible to determine where a resource really is located.

We could have a custom HTTP server, initially for local development, but perhaps even suitable for production with enough caching. The server could build a map, either preemptively or as required, and could service requests for resources. These requests could assume no nesting, and the server would bridge the gap.

[oleersoy]

We would have to solve some simple discrete scenarios first. Suppose we have 2 separate incompatible versions of <dom-repeat>, which is an element that is not rendered, and is only used to repeat other elements. Element A depends on version 1 and Element B depends on version 2.

So we have a document:

<h1>I pity the Foo that can't understand multiple versions of elements!</h1>
<elementA></elementA>
<elementB></elementB>

So as is this would blow up because the transitive dependencies on <dom-repeat> would conflict. Presumably the runtime would detect that <elementB> is using a newer or older version of <dom-repeat> and that would be the end of it.

So that's one type of scenario that has to get solved. Eventually CSS selector application has to be layered into these proposals, so we also need scenarios where we have elements that are rendered, unlike <dom-repeat>, do conflict, and yet we are able to work with and style them with minimum effort.

[jokeyrhyme]

HTML is a global namespace, and CSS is also a global namespace. CSS Modules allows styles to be scoped by renaming every CSS class to a globally-unique name with a build step.

I realise requiring a build step is not desirable, but we could have a similar build step that is similar to CSS Modules. That way, after build, element 1.x and element 2.x don't both define "element", they instead define "element_abc" and "element_xyz".

Where "element" appears in HTML, the appropriate substitution for either "element_abc" or "element_xyz" is made.

[TimvdLippe]

It seems the discussion has evolved and is now actually discussing the details of the webcomponents spec. Note that Polymer does not enforce the "one definition of an element", that is built into the spec. This means that all tooling around webcomponents must make sure that only 1 element definition is loaded for a given name. Therefore I think it is better to discuss this for the specification at https://github.com/w3c/webcomponents

[treshugart]

It seems the discussion has evolved and is now actually discussing the details of the webcomponents spec. Note that Polymer does not enforce the "one definition of an element", that is built into the spec. This means that all tooling around webcomponents must make sure that only 1 element definition is loaded for a given name.

+1, but I just want to add that if there is a use case for having more than one definition on the page that you can use Skate's define() function with Polymer constructors and it will auto-generate and auto-register the element with a unique name. The only caveat is the name is indeterministic, so you'd have to get it using Constructor.is. Hopefully that's helpful. If you have any other questions about using Polymer with that function, please don't reply to this, but please log an issue in the Skate repo.

[oleersoy]

I also started another issue (Rapid prototyping with transitive NPM dependency element resolution) a while back for discussing the scenarios that have to be resolved in order to be able to combine elements from the wild . The underlying assumption is that we would all like to be able to find and use custom polymer elements on NPM, just as we do with other libraries, and that it's possible to do this now without further amendment to the web component spec.

In order for this to happen there are a lot of discrete scenarios that need to be prototyped out such that we can find the THE RUNTIME SCENARIO / SEMANTICS that will allow us to share elements on NPM without running into transitive dependency conflicts.

[timoxley]

Appending the major (or major/minor) version number to the tag would go a long way e.g.
xml <paper-button-1>
It doesn't look very elegant though.

[oleersoy]

Ideally the polyfill would be both native registration and programmatic registration aware. For example suppose I'm upgrading a <login>element that uses <paper-button> v3.4.2 and <paper-input> v5.2.7.

Later I want to plug the <login> element into some banking application for which all the parts (paper-input, paper-button) have major version conflicts with the other elements in the application.

So in other words we can use the <login> element without any registry complaints, but the sub components of it will all trigger transitive dependency registry exceptions.

If the <login> component can create scopes that allow it to instantiate and use the dependencies it needs, outside of what is natively available, then we are home free...famous last words ...

[leogr]

@justinfagnani in the meantime, why can't you just add package.json (no publish on npm) to all sub-projects?

It will allow to install polymer elements as npm packages from Github directly.
Advanced users would benefit from that, because they are used to handle version conflicts resolution in their own building system.

Currently, my company can't use Polymer due to this issue. In the past, I used napa for small projects, but I think it not a good idea if the project has a lot of dependencies.

In case it's not possible, we're thinking about to fork all repos needed and add package.jsons by our self. It's less frustrating than using bower.

[justinfagnani]

We could, be we aren't ready to support those packages even on Github, primarily because they wouldn't have test coverage and we wouldn't know if they work, which would lead to a support cost that we can't handle. When we release NPM packages, we want to know that the package.json files are valid, that we have the correct versions of dependencies, that we've fixed up paths correctly, and run tests against the npm versions of dependencies.

We're getting closer. We have a tool that patches up paths ('../polymer/polymer.html->../@polymer/polymer/polymer.html` as an example). Now we need a release tool that tests both Bower and npm installs and we need npm coverage on our CI servers.

[leogr]

I meant for "advanced user" only, they do not need full support and you do not have to release NPM packages until you are ready. Just add package.json, "advanced user" will figure out how to deal with flattened deps and name conflict resolutions.

As PoC, I've already tested all 2.0-preview as local npm packages (by coping bower.json to package.json and fixing paths)... They works.

BTW, I think the tools tool that patches up paths may be problematics because 3rd-party components are importing ../polymer/polymer.html not ../@polymer/polymer/polymer.html.

Moreover, in this way you're forcing developers to use your tools (even if we do not need polymer-cli, bower, etc...). IMHO this choice is completely wrong.

[FluorescentHallucinogen]

@justinfagnani

What about just create experimental branches with package.json (as long as these packages are not fully production ready)?

What about moving to NPM in 2 stages? The first stage is moving Polymer itself (with all its dependencies). The second stage is moving all other elements made by Polymer team.

Let's look at the problem from a different angle. Imagine we have a module, A. A requires B. Now, let's create an application that requires module A. On npm install, npm v3 will install both module A and its dependency, module B, inside the /node_modules directory, flat. Now, let's say we want to require another module, C. C requires B, but at another version than A. However, since B v1.0 is already a top-level dep, we cannot install B v2.0 as a top level dependency. npm v3 handles this by defaulting to npm v2 behavior and nesting B v2.0 dependency under the module that requires it — in this case, module C.

But what if module A updates at the proper time and requires the same latest stable version of B as module C — B v2.0? In this case, all 3 modules, A, B and C can be installed in a flat way without nesting. I.e. the root of problem is outdated modules that require old versions of other modules, not package manager. Package manager is a tool to solve the problem.

Dependency management is a complex process that requires a lot of resources. Google is a big company that has full control of all elements made by Polymer team and resources to update them at the proper time to use the same versions of dependencies.

[leogr]

@FluorescentHallucinogen I agree with you, but I think we don't need experimental branches.
In order to start experimenting with NPM, package.json should be added to all current branches (e.g. 2.0-preview) for all elements and Polymer team does not have to publish them to the npm's repository quickly. By simply adding package.json there will no side effects.

@justinfagnani For the reason above, you do not need to know if packages work. Let the community try, then you will get feedbacks. Otherwise you would risk to do something that's not really useful for the community.

[oleersoy]

Ideally we would be able to try out packages without needing special tooling at all using the workflow that most NPM users are used to:

1) Clone the repository
2) Run the tests
3) Read up on the tests and local repository documentation

Last time I looked this was not straight forward with Polymer. For instance for the SUIT CSS Grid Component you can just clone the repository and run the NPM scripts to compile, test, watch, and learn more about the Grid component in general. Self contained and easy to work with.

[FluorescentHallucinogen]

Will Polymer 2.0 be released before or during Google I/O 2017? Will the release be available via NPM?

[pomber]

FYI bower is now deprecated:

[gabrieledarrigo]

Yep, any news on this?

[justinfagnani]

We're working on it, but no significant news to share.

Now that I/O is over and 2.0 is released we're planning the next steps and npm is super-high-priority.

Polymer 2.0 was all about a smooth transition to Web Components v1 specs and backwards compatibility. The next changes will probably be around better compatibility with the rest of the JS ecosystem, including of course, npm.

[juliostanley]

@pomber @justinfagnani @gabrieledarrigo @robdodson, just a few thoughts and samples (not that they solve the issue the right way):

Under the assumption that one of the main motivations to support npm/yarn is so it can be used in webpack (other than, well, not use a deprecated client). I have a few observations:

• It has been possible to include polymer via webpack (with a custom loader) for a while (even if installed through bower).

• After some of the recent releases, polymer on npm started using @polymer/polymer which can be installed through npm, but polymer imports shadycss through a relative url which is a problem because it breaks webpack loaders (since @polymer/shaddycss does not exist, but @webcomponents/shadycss does)

• For now, the best way I know to load polymer (or any html import) is using https://github.com/aruntk/wc-loader

• If anyone is interested in setting up webpack, polymer and custom elements you can take a look at this repository: https://github.com/juliostanley/websdk-custom-elements, it loads polymer with wc-loader by default, as well as the paper elements, it also uses babel 7 alpha to transpile and polyfill (it also includes the fetch polyfill)

• I created this package (sorry, hope I don't confuse anyone) in order to download the most up to date Polymer and PolymerElements https://www.npmjs.com/package/@npm-polymer/npm-polymer

I hope this is useful, and do look forward to support for npm/yarn, thanks for the great library and push on web components.

Cheers,

[justinfagnani]

@juliostanley, just a few responses... and a note that we're still working on this.

Under the assumption that one of the main motivations to support npm/yarn is so it can be used in webpack (other than, well, not use a deprecated client).

This is not completely correct. The motivation to move to npm is multifold:

1. Bower is fairly well deprecated at this point, as you point out.
2. Many libraries that users want are more easily, or only, available on npm.
3. We want to be more compatible with a variety of popular tools, including Webpack, but also including Rollup, Browserify, TypeScript, Babel, etc. There are often subtle npm-ism in tools that cause friction.
4. Moving to mpn would mean one less tool.

After some of the recent releases, polymer on npm started using @polymer/polymer which can be installed through npm, but polymer imports shadycss through a relative url which is a problem because it breaks webpack loaders (since @polymer/shaddycss does not exist, but does)

We use relative paths this on purpose and are unlikely at this point to change to package names (though nothing is set in stone yet). Imports of package names do not work on the web, and we want our modules to load without requiring preprocessing or build-steps. Assuming a flat installation, the relative paths works great, just like we do on Bower.

In this case though, it looks like the ShadyCSS import was not updated for the locations of packages on npm, which are different than on Bower. The import of ShadyCSS should be:

<link rel="import" href="../../../../@webcomponents/shadycss/custom-style-interface.html">

Also, it looks like ShadyCSS is only a dev dependence, so if you use custom style you'll need to depend on it yourself. It seems like it should be a normal dependency or at least a peer dependency.

cc'ing @azakus for that ^

I think that once the path is correct, Webpack should be able to handle it fine.

I created this package (sorry, hope I don't confuse anyone) in order to download the most up to date Polymer and PolymerElements https://www.npmjs.com/package/@npm-polymer/npm-polymer

I can't really fault anyone for doing this since it's taking us a long time to get official packages, but I hope that people only use this for experimentation. Once we release our packages, including both in a page _will_ cause errors. Hopefully you can deprecate these when our come out.

[lastmjs]

@justinfagnani Great explanation of why moving to npm is ideal, thanks for writing that up.

[juliostanley]

@justinfagnani thanks!

The motivation to move to npm is multifold

I understand. Personally I do prefer html imports since they are the only thing I can think of, that do not force a build step yet keeps things organized and simple.

In this case though, it looks like the ShadyCSS import was not updated for the locations of packages on npm

Yep

Hopefully you can deprecate these when our come out

Yep experimental, and absolutely! I did not want to do it, but I do want to motivate people to use/migrate to Polymer

Again, thank you!

[FluorescentHallucinogen]

I have a dream that one day Polymer will be based on HTML Modules (and HTML Modules will be natively supported by all major web browsers).

I have a dream that one day Polymer will use NPM/Yarn.

I have a dream that one day Polymer will be written in TypeScript.

[oleersoy]

Dream Baby Dream!!!!

[justinfagnani]

Please don't just bump or +1 the issue. We're actively working on this and it doesn't add to the conversation. There are reactions for that.

[maasencioh]

@justinfagnani I don't see any PR referencing this issue, where's the work being done and how can we help?

[slanted]

I'm glad you guys are moving on this. I think your project is awesome.

Please take these use cases into account:

1. Web Components that get deployed into a Content Management System where each page will have an unknown set of components dragged onto the page. I think Polymer is appealing to many developers coding in this paradigm because of the deduplication of HTML imports. Webpack with the import() statement is knocking on the door here. I'd like to be able to use either, but I'm hoping the HTML imports don't get sacrificed for the webpack build step.

2. At my corporation we will have dozens of developers working on these components, and I don't want them to have to checkout hundreds of git repositories (if a company develops hundreds). So my preferred way to develop would be in a monorepo like babel or react.
   https://medium.com/@bebraw/the-case-for-monorepos-907c1361708a

If you're going to put your elements into npm, then please show folks how to develop in-house components as a monorepo with an approach similar to lerna. I'm curious, do the google developers enjoy checking out dozens of git repos, and what does your CI process look like for these? How does that work when you onboard a developer? Is there a script to pull down all of the git repos? Submodules? Do you use gitflow? Are you forking dozens of repos everytime you do a release? And when finishing the release merge all of those repos back that needed hotfixes? 1 repo. Much easier. Or a few monorepos if you like. But not 1 per component. The guys at component kitchen do this as well. I think the Polymer team should put this approach on their docs and the project will start taking off a lot more because it will ease development among developer groups. Moving from bower to NPM should enable this because you won't need to tie a publish to a git repository. That's why I'm bringing it up here.

1. A developer needs to be able to develop in a linked up environment - either npm link, or soft-links between the components. (Again, see lerna). All I want to do is edit the component files during development and check them into git - no publishing to npm to share until after a release. Most teams still work in sprints that go about 2 weeks, and they share code via git during the development cycle. And again, I'd develop my application as if all my elements were on a CDN. I just want to point my CMS at a doc-root of all of my web components.

I'm hoping that moving to NPM will enable these use cases.

[LasaleFamine]

I think @slanted just resumed almost every problem this switch should solve!
Furthermore I can see we are not the only ones (at my company) to care about the painful situation of maintaining potentially hundreds of repos.
I really hope (and I know) that the Polymer Team's guy's are looking at the community advices, but I'm also scared about the comment of @maasencioh, because we know almost nothing about the progress, but most important the process.

[merlinnot]

@slanted I think this could be an option, but definitely not the only way, my company would suffer if we would have to work in a mono repo.

[oleersoy]

I'm currently working on this css framework. The first thing I did is standardize the project structure for all these repositories. This allowed me to write a set of gulp tasks that work on the same type of project layout making it easy for users since they know they are always getting the same project structure any for all components, utilities, and tasks.

I now have one @superflycss directory that contains all the css components, utilities, and tasks and I can increment on each one individually, which I like because I find it easier to move around and manage each component and utility individually. I believe it's also less intimidating for someone to check this code out as it gives the smallest simplest project set of files that I can deliver. If someone wanted to check out all of these they could just write a shell script to do so. If you want an aggregated subset of these as a runtime dependency just create a new github project that aggregates the dependencies and install it on NPM.

Just my two cents on how this could work.

[slanted]

@merlinnot yes I agree, I didn't mean to imply that. Out of curiosity. Supposing you had 50-100 elements, would you really have a separate repo for each component? If so, what does your setup look like that makes this manageable? Maybe this thread isn't the forum for this and you can let me know through email.

[jenschurchill]

@slanted @merlinnot - I would also be very interested in this.

[pomber]

🎉 🎉 🎉 Polymer 3.0 preview: npm and ES6 Modules 🎉 🎉 🎉

[lastmjs]

How do you install the preview library and elements from npm? The article does not mention how to do so and I can't find any 3.0 version on npm.

[hdelossantos]

@lastmjs Based on this talk at the Polymer Summit, it you just have to use the @next version tag on the dependencies.

[FluorescentHallucinogen]

@justinfagnani @azakus What about ES Modules support (polyfill) in WebComponentsJS?