Polymer / pwa-starter-kit

Starter templates for building full-featured Progressive Web Apps from web components.
https://pwa-starter-kit.polymer-project.org
2.36k stars 431 forks source link

Please import properly... #305

Closed azariah001 closed 5 years ago

azariah001 commented 5 years ago

image

Do I need to say more... official Polymer libraries are currently polluted with this craptastic lack of precision. I'm reporting here because I'm trying to run the PWA Starter Kit on top of my barebones Express instance in preparation for building a full blown web app and here I am discovering that every single /node_modules/@polymer/* import has been written without an opening slash of some description...

image

All they need is to be changed:

//from
import '@polymer/polymer/polymer-legacy.js';
//to
import './@polymer/polymer/polymer-legacy.js';

does exactly the same thing but complies to the standard which I thought was what Polymer was all about.... and yet here I am finding out that the polymer-cli is designed to gloss over glaring issues like this.

What am I supposed to do now? I'd submit pull requests but.... holy heck that's a lot of lines to go correcting... across a lot of repositories...

Dabolus commented 5 years ago

Polymer 3 library and elements use bare module specifiers. This means that you can't use Polymer Elements without something that converts the paths to something usable by the browser. The best thing to do would be to use something to bundle your code and convert the paths. Polymer CLI does this automatically, but you can use any bundler you want (e.g. Webpack works very well).

Making each path start with ./ won't fix your issue, as each element will try to find its imports in its own directory. For example, given this directory structure:

node_modules/
  element/
    element.js
  imported-element/
    imported-element.js

If element.js imports imported-element in this way:

import 'imported-element/imported-element.js';

Most bundlers will automatically resolve the import using node_modules as root and everything will work like a charm, but browsers can't do this automatically and so the code will break without a bundler.

If imported-element gets imported in this way instead:

import './imported-element/imported-element.js';

Both browsers and bundlers will break, as they will try to find imported-element in node_modules/element/imported-element/imported-element.js.

LarsDenBakker commented 5 years ago

Not hardcoding the module directory in your source code let's you write and share code at scale. It is becoming the de factory standard, and work is being done to standardize it: https://github.com/domenic/import-maps

For express there is a simple middleware: https://github.com/nodecg/express-transform-bare-module-specifiers

azariah001 commented 5 years ago

Thanks @LarsDenBakker.

I really disagree with the move away from absolute paths in the code base (at least within a single module). I do understand the argument from the perspective of including other modules in a project, however. Having been around since the 0.x days I remember the mess of ../../ we had to do to include things from other modules in Bower... do not miss those days for sure.

As for requiring the use of a code bundler to even do development.... please don't! I'm glad this express middleware exists otherwise I'd be up a creek with no paddle right now. Polymer is a frontend UI library not a server-side framework so enforcing the use of xyz build tools on the backend shouldn't ever enter the discussion, especially when you're publishing the whole project on NPM, anyone should be able to grab Polymer off of NPM and include it in a project with very little fuss.

May I suggest that this middleware should be added to the Polymer install dependencies, and include a print to the npm install log that if you're using express you'll need to include it in your codebase? :grin: