switch from bower to npm?
jab opened this issue · comments
(Apologies if this has been discussed already; I couldn't find it in the tracker.)
Does the Polymer team have any plans to move from bower to npm in light of e.g.
Why We Should Stop Using Bower - And How Written a few months ago, now npm 3 is out with flat deps, so even better!
It was responded here https://youtu.be/D7ZSMw_qm8Q
Thanks @martinsthiago! So according to that, once npm supports conflict resolution, Polymer will switch. I looked in https://github.com/npm/npm/issues for a corresponding issue to reference but didn't immediately find one. Is that being tracked? /cc @robdodson
What is meant by npm doesn't support conflict resolution? npm@2 will install dependencies in a hierachy based on the original component... npm@3 will dedupe/reduce the hierarchy under node_modules, when there is a conflict there will be a child reference under the package.
See also require.resolve()
That said, it would be nice if the module (including bower_components) directory could be published to npm as part of the regular test/publush flow, as it's seriously out of date compared to the current version...
One thing that's a little strange is that there's a brand new thread on this. A lot of use are still wondering why the previous thread remains closed? Publish sub-projects on npm, add them to package.json.
Polymer really needs to strongly consider whether insisting that the package manager do conflict resolution is a good idea (In terms of impact on developer productivity, scalability, and the eco system).
How about starting a Polymer 2.0 branch that allows us to publish and consume components via NPM without having to worry about conflict resolution? This was solved a long time ago by OSGi (JDK9 Jigsaw), and NodeJS, so surely there's a way for Polymer to take advantage of the progress made in this space as well?
@oleersoy there's a thread on this every couple of weeks :)
From my perspective, we're simply not ready to make a move yet. Switching our recommended tooling (one that developers have been using with us for the past few years) to npm3 (a new version which many people still do not have) is a big ask and something we can't do lightly. Polymer 2.0 is an interesting idea, but it sounds like a maintenance nightmare. We just hit 1.0 and there is much to do! My dream is a Polymer 2.0 written in ES6 that uses npm3. Someday. Somewhere. Somehow. But we're not there yet.
If you're interested in using npm, @addyosmani posted a possible stop-gap that might work, though it looks like it doesn't bring down the transitive dependencies.
#2525 (comment)
@oleersoy there's a thread on this every couple of weeks :)
Good point :)
From my perspective, we're simply not ready to make a move yet. Switching our recommended tooling (one that developers have been using with us for the past few years) to npm3 (a new version which many people still do not have) is a big ask and something we can't do lightly.
How about starting a 2.0 branch with nothing in it. Just start from scratch. Then get the community involved in answering the question "How do we support versioned elements?"... and let it flow from there...after that start publishing a minimal set of packages on NPM. This could move really fast. There are so many freaky smart people working this.
Is there a good way to monitor npm 3 adoption vs. bower adoption, since that was a concern @ebidel raised? I didn't immediately see a way to filter e.g. http://www.npm-stats.com/~packages/npm by ≥ 3, to make it a fairer comparison against http://www.npm-stats.com/~packages/bower.
there's a thread on this every couple of weeks :)
Just wanted to echo my earlier "(Apologies if this has been discussed already; I couldn't find it in the tracker.)".
Similarly, the first page of https://groups.google.com/forum/#!searchin/polymer-dev/npm$20bower doesn't yield obviously relevant threads when I check, unless I missed something.
Feel free to ignore: when Bower was first being put together, we ran into a few issues with adoption amongst popular JavaScript libraries and frameworks. Some didn't want to to adopt a bower.json file nor think about supporting the various package.json, component.json and other <flavor-of-the-month>.json files.
So, https://github.com/components was used to achieve this end-goal instead. It's basically shim repos that contain the built assets of each library in a way that can be easily installed using npm or any other package manager. In theory, something similar that's community driven could be done there for Polymer.
The biggest challenge with handling the transitive dependencies is that Polymer and the various element collections constitute a lot of repositories that would require shimming. You could potentially forgo this and just have a single polymer-elements package that is generated by the release process (@azakus maintains) and has the latest and greatest of all the element collections (or a subset).
That would make installing via npm easier, but shifts responsibility to vulcanize/build processes to properly copy whatever end assets you want over rather than leaving them in node_modules. Imo, this isn't such a bad idea. It doesn't give you the full modularity you might want but until Polymer officially supports npm it might be a not-terrible stop gap.
Other alternatives are relying on Git commit hashes and trying to see how far we can get with the npm3 flat dependency structure in terms of managing dependency paths.
Other alternatives are relying on Git commit hashes and trying to see how far we can get with the npm3 flat dependency structure in terms of managing dependency paths.
My question with respect to this is "Is Polymer assuming that the entire eco system is going to be able maintain a friendly and easy to work with set of 'Flat dependencies'"?
I just wondering if something is off in my thinking...it looks like Polymers eco system could be made up of thousands of components eventually (Next 3 years), with many component being composed from others. As we develop products that use these component sub assemblies, if we insist on a flat dependency graph, is there some way to get around 'dependency hell'?
@ebidel You have the option to duel publish and it adds very little overhead. I'm building a large Web app using Polymer (not elements) and Polymer is the only dependency I have that requires Bower.
Also, bower is currently on life support: https://www.reddit.com/r/javascript/comments/3sol5h/bower_development_effectively_stopped/
I'm not asking you to change every repo and all tooling overnight, but it would be great to provide the npm option to those who really don't need Bower.
I've restarted conversations with the eng. team around us defining an official npm story for Polymer. Will keep this thread updated. Keep in mind we want to do this in a way that's clear and low-effort for end users rather than trying to rush out support that doesn't integrate well with our current release process for elements.
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.
A starting point for this support would just be publishing a script library of Polymer to npm.
Closing in favor of #326
Did Polymer ever get published to NPM?
@MarkPieszak Yes we've published to npm. npmjs.com/~polymer
More context is in the #326
Thanks Rob! Wow so many things I'll have to take a look to see which ones I need :) @robdodson
Guys, there's currently only 0.0.5 version of Polymer in npm?
All of the Polymer code and elements on npm are horribly out of date. Why? And why have them published there at all if the versions published are 3 months old?
As @robdodson said, please see: #326 (comment) for context and further discussion.
