Paper Elements can't be natively imported

[gkjohnson]

Hello! It's great to see that Polymer 3 with modules has been released! However, it looks like the migrated Polymer NPM elements (like paper-button) rely on "bare" module dependencies, which results in the following error when importing into the browser:

Failed to resolve module specifier "@polymer/polymer/polymer-legacy.js". Relative references must start with either "/", "./", or "../".

I understand the issues associated with relative path imports and that we can use "Rollup" or "Webpack" to build a project, but one thing I've always appreciated about Polymer is that you don't need a build process and, in my opinion, this requirement is a pretty big step back and makes migration for existing projects pretty difficult.

Is there any plan to allow these Polymer elements to work without a build process? I've seen the package name map proposal, but that seems like it will be a long way out and isn't even poly-fillable.

Would the Polymer team consider providing two versions of the migrated elements? paper-button.js and paper-button.relative.js, for example -- one with relative paths and one with bare modules? That way existing projects can choose to import the relative package modules for an easy upgrade.

Thanks!
Garrett

[kevinpschaaf]

You may already be aware, but the Polymer CLI's built-in serve and build commands can perform only that transform (module specifiers to URL paths) on the fly, leaving everything else uncompiled native ES modules.

If you'd like to go one step further and not perform this transform on dependencies during dev time at all, we have an experimental script you can add as an npm postinstall step on your application which will do a one-time transform of module specifiers to paths in your npm dependencies. This is experimental and we don't have any SLA around support, but feel free to try and see if it helps your workflow: https://github.com/PolymerLabs/empathy/tree/initial-implementation.

There has been discussion in the past with npm on whether an option to do this for front-end dependencies could be folded into npm as a first-class feature. So depending on developer feedback and demand, and progress on package name maps and npm changes, that project could get more or less attention or go away altogether.

All that said, we don't have any plans to publish two entry points for components, so I'm going to go ahead and close this issue.

[gkjohnson]

Hey @kevinpschaaf, thanks for the response! Empathy looks closer to what we're looking for, though it's a little heavy handed. I'll definitely look into it a bit more and give some feedback!

All that said, we don't have any plans to publish two entry points for components, so I'm going to go ahead and close this issue.

Can I ask what the expected path forward is for existing projects (or even new ones) looking to migrate to Polymer 3.0 and the new paper elements? In the prior versions it's been possible to just statically serve the files for development -- the upgrade guide doesn't cover this case.

the Polymer CLI's built-in serve and build commands can perform only that transform (module specifiers to URL paths) on the fly

I did see that, but is it expected that a project suddenly have to use this if they even import just one paper element? Or if the project already has a static-file serving solution?

I understand that the new import spec has left the js package world in a bit of a awkward spot. I'm sure there will be some kind of solution in the coming years to address this issue (either through tooling or new spec), but it would be nice to have some simple migration path forward in the interim.

I do feel obligated say that I really appreciate the work put into version 3 and the upgrade documentation. Aside from this hiccup, the upgrade and everything else has been really clean.

Thanks again for responding, I appreciate your time!

[kevinpschaaf]

Yes, this was a very, very hard call for us to make, as we're as big of proponents of tool-free edit/refresh developing as they come. We agonized over this decision in more meetings than I can count, frankly.

But on the whole, the barrier to entry of requiring flat installation of all dependencies required to use path-based module specifiers (when a large percentage of the OSS JS world does not currently and likely will never agree to that limitation) means a lot of developers were sidelined from stepping into the web components ecosystem altogether, and that just didn't feel like a tenable spot to continue to stay in.

Can I ask what the expected path forward is for existing projects (or even new ones) looking to migrate to Polymer 3.0 and the new paper elements? In the prior versions it's been possible to just statically serve the files for development -- the upgrade guide doesn't cover this case.

It's fair that the upgrade paths we mostly focused on were either a.) someone using the Polymer CLI for the dev/build workflow (which should hopefully be a seamless transition), or b.) someone happily using basically any other toolchain that can ingest code from npm (meaning they can already deal with module resolution), but not this third case which is "was using neither the Polymer tools nor need to work with other npm packages, and thus was happy with a purely static server."

So at least for the time being, I think the answer to your question is one of 1.) Polymer CLI, 2.) WebPack, Rollup, and friends, or 3.) empathy -- with a hopeful future of Package Name Maps, npm asset support, or both.

[gkjohnson]

I understand -- it doesn't sound like it was an easy decision or an easy problem to solve. We'll probably look into empathy for the time being.

Thank you!

[JeanRemiDelteil]

@kevinpschaaf

Yes, this was a very, very hard call for us to make, as we're as big of proponents of tool-free edit/refresh developing as they come. We agonized over this decision in more meetings than I can count, frankly.

That is really the best experiences indeed.

[...] but not this third case which is "was using neither the Polymer tools nor need to work with other npm packages, and thus was happy with a purely static server."

This case covers basically everyone using Firebase hosting a little heavily (to host a real world app with some functionalities).

That said, using empathy to sort of statically one time rewrite the imports seems like a viable options, if it works and is not something that will disappear.

[jogibear9988]

@kevinpschaaf Is there a reason why there is no release of empathy till now? Are there any actual statements about "tool-less" development?

[jogibear9988]

maybe also @TimvdLippe you can give an actual statement here. Or maybe someone can add a little bit of a description about only changeing "import paths" on polymer or lit-ement page?

[TimvdLippe]

I don't have any more information on empathy, sorry. You might be interested in this project: https://github.com/pikapkg/web