Polymer 3.0 doesn't play nice with firebase serve at all

[JeanRemiDelteil]

Description

Using Firebase hosting for a polymer app is much more difficult with Polymer 3.0 than previous version:
simply because we can not use firebase serve anymore.
The app needs to be served by polymer serve to rewrite every package import (which is a horrible useless step imho).

The problem lays with running a server with the correct settings such as Url rewrites or redirections, file serving settings, etc...
We have 2 solutions for running the app, however, neither of them is taking in account all of these requirement, and more than that, they don't allow middleware that could solve this issue, or interact with each other to solve this:

polymer serve will break the server settings and only correctly edit the code live...
firebase serve will correctly serves the files and urls, but not rewrite the code, so it will not work.

That's pretty awesome to make new stuff, but don't go saying that we can use Firebase if we can't even ran it for tests. If I 'build' my app statically every time I want to test something it would takes useless hours for nothing, simply not thinkable.

Live Demo

Every polymer 3 app hosted on Firebase hosting, using firebase hosting features (such as Url rewrites, redirections, etc...)

Steps to Reproduce

1. Write a Polymer 3 app
2. Use Firebase hosting with Urls rewrites
3. Try running your app locally (testing)

• either using polymer serve
• or firebase serve

Expected Results

App run fine, following hosting settings such as Url rewrites and every other settings allowed by Firebase hosting.

Actual Results

When running polymer serve your app will actually boot-up, but all the logic is broken and you can not test it as expected.
When running firebase serve your app files are correctly served according to hosting logic, but the code will break on import, as Javascript can not import node package syntax.

Browsers Affected

• [x ] Chrome
• [ x] Firefox
• [ x] Edge
• [ x] Safari 11
• [ x] Safari 10
• [ x] IE 11

Versions

• Polymer: v3.x

[TimvdLippe]

This was a hard decision to make, but given our move to the NPM ecosystem and their convention of using named imports, we had to accommodate. We have a more in-depth discussion at #5238 (comment) which also lists the tool empathy that we are experimenting with. This will run for all of your NPM dependencies on install time, so that you can use paths during development. Would that work out for you?

[Westbrook]

One alternative is to polymer build and then firebase serve those assets. I was already doing that with my Polymer 2 project, so it’s been a pretty simple transition. If you wrap the commands together in an NPM script, it’s even simpler. I go so far as to gather updated dependencies at the same time via my script to make sure I’m 100% up-to-date with each serve.

[JeanRemiDelteil]

@TimvdLippe : There is indeed some inconsistencies between JS front-end and using NPM (I'm not questioning the choice of respecting NPM rule, rather the answer of --> use polymer serve / re-build your app every time.)
I think that the empathy tool, by one-time rewriting the import will fix this issue completely.
However it needs to feel solid enough for me to commit to a whole shift on Polymer 3 / empathy / NPM (though it feels natural described like this)
Speaking for myself here ;) but I feel that everyone having to make those choices for a production project will be in the same seat.

I will check this well named empathy tool to get a clearer view !

@Westbrook : That is totally not an option.
Reasons are simple:

• It takes more than 60sec to build the app. It's a webapp, not that complex, so there are bound to be more complex project out there.
• I'm already not using polymer build or serve or anything. Having the needs for complete control over the process, the build is using polymer-build and other tools in a custom build process.

[CaptainCodeman]

60 seconds to do a build seems incredibly long. Especially when developing there should be some caching to speed things up and shorten the edit / update cycle - 'how' will depend on the exact build tooling but most of the big name ones have some options that can help.

It's a shame that the module imports don't work like normal http requests, I don't understand the reason for not having the pathless imports supported - otherwise the resolution could be handled at the server by having a thin layer of node-resolution middleware, much less intrusive than having to parse and re-write content.

But I believe the re-writing part is middleware so the solution is to combine this with the firebase (or any other) hosting for development if you can't speed up the build (or don't want to). Maybe this could be using the proxy & live re-loading features of one system (e.g. browser-sync) working with firebase serve.

I don't think adding more Polymer specific tooling is the right solution.

[JeanRemiDelteil]

I agree that it's a long time to build. Though as a small team we can't really spend all our time on refactoring the build process every time there is a new tooling set out-there (though we try to keep up).
So currently it's working, but takes time (even 30sec would still be too much [for live reloading] actually).

Also it feels like there is a real issue with loading imports from NPM. Not just a Polymer issue.

[kevinpschaaf]

As @TimvdLippe said, the choice to adopt using npm package names for dependencies rather than paths was a difficult decision, but one we feel has more upside than downside, especially in light of a platform-based solution coming on the horizon.

That said, this is a decision we're not currently re-considering. In the interim, we're in the same boat as literally all other mainstream front-end development workflows, meaning some sort of transformation is required between npm dependency install and running in the browser. However, we have the benefit of only requiring a very light transformation to make them loadable (names to paths) which we expect will go away in the future.

The empathy post-install tool seems like the ideal fit for your use case, since it mimics an experience similar to what package-name-maps will ultimately provide.

I'm closing this issue since there is nothing in the polymer core codebase we would do to address your issue.