Some dependencies for demo pages give http status 400

[ergo]

Hello,

I've an element that works properly using polymer serve, howerver on webcomponents org some files are not being served to the client and end up with http status 400.

https://www.webcomponents.org/element/polymer-ui-router/demo/demo/index.html

[mlisook]

I have the same situation. Just like your example it starts with a 400 status code on webcomponentsjs.

https://www.webcomponents.org/element/plastic-resize-aware/demo/demo/index.html

Is this an issue with the raw-dot-custom-elements service as opposed to webcomponents.org?

[samuelli]

sc-fitted-text is fixed in our latest updated now!

[ergo]

@samuelli Seems like most of dependencies are loading for my demos here: https://www.webcomponents.org/element/polymer-ui-router (iframe page) https://raw-dot-custom-elements.appspot.com/@@npm/polymer-ui-router/3.0.1/polymer-ui-router/demo/index.html

however iron-helpers and webcomponentsjs polyfill do not load - I have them listed as devDependencies. Is that something that can be corrected easily? I'm not sure if it would be proper to list them as normal dependencies.

[samuelli]

Hey @ergo,

I've been working hard on a big update to serve our demos for NPM based packages. It's finally all landed now and I'm pretty happy with how its gone. There's a lot of edge cases and brittle areas just as a result of the landscape.

AFAIK, the demo you have above no longer has issues with devDependencies. That's all fixed in the new update. However, there is a polymer conflict. My current recommendation is that you update these lines https://github.com/ergo/polymer-ui-router/blob/master/demo/index.html#L12-L15 to use bare module specifiers instead. To do that, you'd have to change it to something like:

<script type="module">
  import '@polymer/polymer/polymer-legacy.js';
  import ...
</script>

With that change, your demo should work!

[LostInBrittany]

Hey @samuelli !

I've tried to do as you suggested, and I get a conflit

You can see the detail here: https://www.webcomponents.org/element/@granite-elements/granite-alarmlight/2.1.2/demo/demo/index.html

The browser loads two versions of dom-module.js :

• https://demo-dot-custom-elements.appspot.com/@polymer/polymer@%5E3.0.5/lib/elements/dom-module.js imported by the import in my element
• https://demo-dot-custom-elements.appspot.com/@polymer/polymer@%5E3.0.0/lib/elements/dom-module.js imported by prism-theme-default.js

As they are two different versions, with two different URL, browser doesn't deduplicate them and it tries to load both of them, getting a good conflict:

    at https://demo-dot-custom-elements.appspot.com/@polymer/polymer@%5E3.0.5/lib/elements/dom-module.js:138:16

I think it's the same problem that @ergo had, but if you prefer I can post it in a new issue...

[LostInBrittany]

O.K., I got it working, but it's still a bug.

The version in error: https://www.webcomponents.org/element/@granite-elements/granite-alarmlight/2.1.2/demo/demo/index.html

Working version: https://www.webcomponents.org/element/@granite-elements/granite-alarmlight/2.1.3/demo/demo/index.html

To make it work you need the polymer dependency on your package.json to be exactly

 "@polymer/polymer": "^3.0.0"

Why? Because the demo setup currently seems to load the dependencies for each element using the version on declared on package.json for that element!

So let's say that my element has a dependency "@polymer/polymer": "#^3.0.5" but my demo uses @polymer/iron-demo-helpers/demo-snippet that has "@polymer/polymer": "#^3.0.0" on its package.json.

The demo page then loads polymer dependencies from https://demo-dot-custom-elements.appspot.com/@polymer/polymer@%5E3.0.5/ when loading my component, but it also loads polymer dependencies from https://demo-dot-custom-elements.appspot.com/@polymer/polymer@%5E3.0.0/ for demo-snippet. As the two URLs are different, they are different modules according to the browser.

I think the demo page should try to use the unified version of package-lock.json for all the dependencies, that would eliminate the problem.

[samuelli]

@LostInBrittany: thanks for all that.

I was already aware of the problem and had come to the same conclusions about how to resolve this. Unfortunately, it took me a while to implement running into lots of issues, but #1220 should address this. I tested manually with your broken package (2.1.2) and it works. However, it is pretty slow simply because generating the package-lock.json can take some time depending on the package we're installing. The fact that devDependencies are needed aggravates this issue.

You can try it out but you may see faster results since generation may be cached.

[LostInBrittany]

That's great, @samuelli !!! Thanks again!