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.

[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 "myComponent@1.0" and "myComponent@2.0", 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 notifications@github.com 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 ...