Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use web standards for imports in polymer library #5514

Closed
jarrodek opened this issue Mar 27, 2019 · 2 comments
Closed

Use web standards for imports in polymer library #5514

jarrodek opened this issue Mar 27, 2019 · 2 comments

Comments

@jarrodek
Copy link

Description

Most of project's files uses web standard when importing dependencies (e.g. import { dedupingMixin } from '../utils/mixin.js';. However lib/elements/custom-style.js and lib/legacy/legacy-element-mixin.js uses Polymer's import syntax for files located in @webcomponents library.
This makes it difficult to use the library without using polyserve. When developing apps that are not running in the web (Electron, Chrome app) it is required to take additional steps in order to make it run in dev environment (compilation on source file change, some other measures).

I would like to see the @webcomponents imports to comply with web standards so the library can be used directly in the web browser without using Polymer tooling.

@kevinpschaaf
Copy link
Member

Closing as duplicate of #5238 (comment) and #5431 (comment). Please see those threads/comments and a blog post on the topic for more details on the reasoning that went into the decision-making for package names being the only non-standard convention used in published Polymer Project source.

Also, Chrome intent to implement import maps and @pika/web are two exciting new areas worth following in this space.

@jarrodek
Copy link
Author

Thanks for the links. I was asking on Polymer Slack channel some time ago about reasoning behind this decision but didn't get the answer. Reading this comments I think everything has been said already about that. My humble opinion is that the platform should be first, not tooling. Although, I do understand the reasons behind that decision now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants