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.

👍

[ghost]

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

[knownasilya]

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

[glassresistor]

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

[glassresistor]

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

[briandipalma]

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

[sjmiles]

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

[ericelliott]

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

[glassresistor]

+1

On Mon, Aug 18, 2014 at 6:24 PM, Eric Elliott [email protected]
wrote:

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

—
Reply to this email directly or view it on GitHub
#326 (comment).

Mikela

[kristoferjoseph]

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

[kartesus-zz]

👍

[kolodny]

👍

@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.

[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?

[justinfagnani]

@FluorescentHallucinogen it's not so easy to polyfill <script type=module> because you need a whole JavaScript parser. There is one already though, here: https://github.com/matthewp/script-type-module

More common is to make things work at compile time. We're already integrating Babel's module transform in polyserve to automatically compile modules to AMD, and then use RequireJS to load the files. This is nice because we can do the compilation on a per-file basis, and don't have to bundle.

[juliostanley]

@justinfagnani it is great to see the official preview release of npm packages, I sent a request to npmjs to remove the @npm-polymer packages (not allowed to unpublish packages).

For anyone who happened to experiment with @npm-polymer and is using webpack, I updated the sample project to use the latest version of Polymer 3.0 built with webpack (this time without any special webpack loader for polymer, it does transpile the code to ES5 though)

Sample project:
https://juliostanley.github.io/websdk-custom-elements
https://github.com/juliostanley/websdk-custom-elements

[mgol]

I sent a request to npmjs to remove the @npm-polymer packages (not allowed to unpublish packages).

You should just invoke:

npm deprecate @npm-polymer/package-name "Deprecation message pointing to the new packages"

Packages cannot be unpublished for a reason, you'd break those people that use your packages. Unless there's an issue with copyright etc. your packages won't be allowed to be unpublished.

[FluorescentHallucinogen]

@justinfagnani

Everything is clear with Polymer CLI. But what about using elements (not apps) without compilation and using pure / non-Polymer web components?

If I understand documentation correctly, Polymer CLI is 1. designed for Polymer projects, 2. designed for serving elements and apps, but building only app projects, not individual elements.

BTW, is it a good practice to build web components (minify JS, CSS, HTML and optionally transpile ES6 to ES5 and generate sourcemaps) at all e.g. before publishing?

The first problem is the new Custom Elements spec based on ES6 syntax, but ES6 is not supported by older browsers. Are there ES6 polyfills that allow to use web components with ES6 class definition without ES6 to ES5 transpilation?

What then is the future of WebComponentsJS after deprecating HTML Imports in favor of ES Modules? Now I can just load WebComponentsJS polyfills and use web components in browsers that don't support HTML Imports without any compilation. Seems this is not possible with ES Modules web components.

What about polyfilling dynamic imports of ES Modules? Currently Safari Technology Preview supports dynamic modules imports, but Chrome Canary not. Dynamic imports is needed to do lazy loading, one of the principles of PRPL pattern that is used for PWAs.

What is the future of PolyGit CDN? After switching from Bower to NPM will PolyGit be deprecated in favor of unpkg CDN?

What about adding JS, CSS, HTML minification, ES6 to ES5 transpilation and generating sourcemaps options to PolyGit for all elements?

[FluorescentHallucinogen]

@samuelli

According to https://webcomponents.org/community/articles/web-components-org-update, all demos on https://webcomponents.org, including inline demos are already automatically transpiled for browsers that don't support ES2015 syntax.

What about the idea from my previous message of adding JS, CSS, HTML minification, ES6 to ES5 transpilation and generating sourcemaps options to PolyGit for all elements and using it instead of https://raw-dot-custom-elements.appspot.com on https://webcomponents.org?

BTW, is it possible currently preview/publish NPM elements on https://webcomponents.org?

[justinfagnani]

@FluorescentHallucinogen

BTW, is it a good practice to build web components (minify JS, CSS, HTML and optionally transpile ES6 to ES5 and generate sourcemaps) at all e.g. before publishing?

No, component should be published as standard ES6 and compiled, if at all, at the application level. The application is the only thing that knows the target and serving environments. If you compile your components when publishing, you force your users to compile their apps so that they can use the custom-elements-es5-adapter, which means you won't get any users who wish to use no polyfills/adapters on Chrome and Safari.

The first problem is the new Custom Elements spec based on ES6 syntax, but ES6 is not supported by older browsers. Are there ES6 polyfills that allow to use web components with ES6 class definition without ES6 to ES5 transpilation?

The only way to "polyfill" ES6 is to compile it to an earlier version of JS.

What then is the future of WebComponentsJS after deprecating HTML Imports in favor of ES Modules?

Same as it ever was. I guess we'll need some changes to the loaded to opt-out of HTML Imports.

Now I can just load WebComponentsJS polyfills and use web components in browsers that don't support HTML Imports without any compilation. Seems this is not possible with ES Modules web components.

Like any use of JavaScript, you may to compile newer features down to the target platform. Polymer 2.0 already required compiling out ES6 for platforms like IE11. Polymer 3.0 will require compiling ES6 modules for IE11 too. For the modern browsers, modules will load natively very soon in all 4 major browsers.

What about polyfilling dynamic imports of ES Modules? Currently Safari Technology Preview supports dynamic modules imports, but Chrome Canary not. Dynamic imports is needed to do lazy loading, one of the principles of PRPL pattern that is used for PWAs.

Dynamic import() is not really polyfillable, that's why we're waiting for it.

What is the future of PolyGit CDN? After switching from Bower to NPM will PolyGit be deprecated in favor of unpkg CDN?

I would love to just use services like unpkg rather than running our own. One of the major goals here is to be just another library with respect to most tooling and services like this so you can just use whatever works without requiring special support from us.

[lastmjs]

How will you import scripts that are not modules? For example, I have various components that use script tags to import some dependencies in their HTML files. When HTML imports go away, I don't see how I can load those scripts with my components, since they aren't modules that can be imported with the module syntax.

[justinfagnani]

Sometimes, non-module scripts can be loaded via import. If they don't depend on any of the differences between modules and script, they often just work. If not, then you either need to use something like Rollup or Webpack today, or we'll be working on some kind of require shim soon (which will require bundling non-module dependencies during dev)

[nazar-pc]

I'm amazed that this issue is opened since 2013 and with Polymer publicly committed to move to NPM, version 2.5.0 still uses <link rel="import" href="../../../shadycss/apply-shim.html">.

@azakus, this is a one minute change, fix shadycss paths, please.

[justinfagnani]

@nazr-pc I'm at a lost for context here. What is wrong with the path? Seems like this is the wrong issue to discuss it.

[nazar-pc]

I'm talking about these lines:
https://github.com/Polymer/polymer/blob/master/lib/elements/custom-style.html#L10
https://github.com/Polymer/polymer/blob/master/lib/legacy/legacy-element-mixin.html#L11

I install Polymer 2.5.0, include polymer.html (intentionally legacy version) and it doesn't work unless I manually edit installed files afterwards.

[justinfagnani]

Those paths look correct to me.

[nazar-pc]

@justinfagnani, they are not, as there is no node_modules/@polymer/shadycss and there is no package @polymer/shadycss.

Those lines should be:

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

Which I guess you'll need to change manually each time before publishing to NPM since otherwise it will break your Bower package or add @polymer/shadycss package to NPM. This is why I don't like hardcoded paths Polymer advertises everywhere.

[justinfagnani]

The master branch works with Bower, not npm. The corresponding line for Polymer 3.0 on npm is: https://github.com/Polymer/polymer/blob/__auto_generated_3.0_preview/lib/elements/custom-style.js

Soon that will use package names instead of relative paths to import.

[nazar-pc]

Doesn't really matter what master branch is using. Polymer 2.5.0 is on NPM and it is broken.

I've read that, package names that make Polymer unusable without custom build tools, not a better alternative for me.

[web-padawan]

I was wondering if you guys were going to close this Biggest Issue Ever during the live session 😀 Apparently not. But I guess it can be closed now, right?

[justinfagnani]

🎉 Now that Polymer 3.0 and Polymer Elements are officially published to npm, and the I'm very, very happy to close this issue! 🎉

Huge thanks to everyone who hung in there over the years as we made this transition! I know it was slow at times, but I think we landed in a very good place by moving to JS modules too and becoming much more compatible with the rest of the JavaScript ecosystem.