menu

pika

📦⚡️A project to move the JavaScript ecosystem forward.

Channels
Team

Simple web-component with pika pack

March 11, 2019 at 8:33pm

Simple web-component with pika pack

March 11, 2019 at 8:33pm

We're starting a new component project and application project and are interesting in using pika (the opinionated way). Currently, we typically build a component library project (like https://github.com/material-components/material-components-web-components) and an application project (like pwa-starter-kit), and link the dependencies so that component development in the component project will be reflected to the application project.

That aside, some thoughts: It seems like the obvious pattern is to use pack build within each component folder, and pika-web for the application project. But what about the import paths inside of the "standalone" web-components? Should those follow the same web_modules conventions (example: import { LitElement, html } from '/web_modules/lit-element.js';? or do we leave that up to the application to resolve? The out-of-the-box convention for the above example is to use import {html} from '@polymer/lit-element/lit-element.js';. Do we leave that as-is for our standalone component, then let pika-web figure that out for us on the application side? Maybe we're jumping ahead and we should avoid pack build with our individual components?

Lots of moving parts here, any input is appreciated! We'd love to document the pattern here.


March 11, 2019 at 8:34pm

Also, first time using Spectrum here, please be lenient on the formatting!

like-fill
1
  • reply
  • like

This is my first time using Spectrum as well, and it seems like they don't love @mentions inside of code blocks. Anyway, welcome!

  • reply
  • like

Polymer has a history of first promoting ESM imports by path, and then later imports by package name. This probably muddies Pika's distinction between the two a bit more for the web component community than it does for others who really haven't imported dependencies by path in 5+ years. (I take some responsibility for this, I was on the Polymer team at the time :)

Edited
  • reply
  • like

pika/web is a dependency installer, so it should work for any project (apps or libraries). The problem is that packages being published to npm need to import dependencies by package name, which means they aren't truely web native (at least today) and couldn't be served directly to the browser.

Edited
  • reply
  • like

The closest thing I can give you to an answer is to use the pika/web Babel plugin (see the readme quickstart for an example)

  • reply
  • like

This way you can:

  • Write with package names in src/
  • Use Babel to build an identical lib/ directory with imports by package name transformed into imports by web_modules/ path, for testing
  • Use pika/pack to build your package, preserving imports by package name for npm
  • reply
  • like

(Or, use something more powerful like Jest for testing, which should "just work" with package name imports)

  • reply
  • like

Ok, I have something working™. I pulled mwc-card from the material web components (https://github.com/material-components/material-components-web-components/blob/master/packages/card/mwc-card.js)

like-fill
1
  • reply
  • like

There is one path I needed to update, and that is the import {LitElement, html} from '@polymer/lit-element/lit-element.js';

  • reply
  • like

That needed to be changed to import {LitElement, html} from 'lit-element';

  • reply
  • like

I moved the source files into a /src directory, and renamed mwc-card.js to index.js

  • reply
  • like

updated the package.json to use the build plugins from the readme, verbatim.

{
"name": "@sample/mwc-card",
"description": "A simple example Pika package",
"version": "1.0.0",
"scripts": {},
"license": "MIT",
"main": "src/index.js",
"@pika/pack": {
"pipeline": [
[
"@pika/plugin-standard-pkg",
{
"exclude": [
"__tests__/*"
]
}
],
[
"@pika/plugin-build-node"
],
[
"@pika/plugin-build-web"
]
]
},
"dependencies": {
"lit-element": "^2.0.1"
},
"devDependencies": {
"@pika/plugin-build-node": "^0.3.4",
"@pika/plugin-build-types": "^0.3.4",
"@pika/plugin-build-web": "^0.3.4",
"@pika/plugin-bundle-web": "^0.3.4",
"@pika/plugin-standard-pkg": "^0.3.4",
"@pika/types": "^0.3.4"
}
}
  • reply
  • like

next, run pack build

  • reply
  • like

navigate to newly generated /pkg directory, run npm link

  • reply
  • like

navigate to application project, run npm link @sample/mwc-card

  • reply
  • like

run npm run prepare (pika-web)

  • reply
  • like

bing bang boom, it works

  • reply
  • like

@fks sorry for the deluge. One thing to confirm. My module name @sample/mwc-card was pulled given the filename @sample--mwc-card in web_modules. That makes the import a little bit ugly. import '/web_modules/@sample--mwc-card.js'; Is that filename expected?

Edited
like-fill
1
  • reply
  • like

nice! So happy to hear it was that easy

  • reply
  • like

not a deluge at all, so excited to see the final product if you have it hosted somewhere / forked on github

  • reply
  • like

That is intentional, we convert all / to -- so that web_modules is flat, but we've definitely gotten mixed feedback on that.

  • reply
  • like

knowing that it's expected, would love to hear your thoughts/feedback

  • reply
  • like

March 12, 2019 at 1:57pm

I'm curious from a developer experience standpoint. I think it's a weird caveat to tell our developers "yea the docs for that use this file path, but over here you need to replace that dash with a slash"... unless it's a transform that happens as part of a build (which defeats the purpose), or if we only use the modified path in something like an entrypoint, or maybe if we reference a compiled imports file - which feels like a bundle. Still playing with it though!

like-fill
1
  • reply
  • like

An origin for this that might pose a solution: I'm having flashbacks to Polymer when developers would publish components to bower with the same component name despite preexisting component collections (ie. paper-*), which in turn, mandated that bower references always include the organization scope (ie. PolymerElements/paper-*). If that wasn't an issue, then we would just reference everything without the org scope.

For the sake of discussion: In the case of our above example, there aren't any packages (in this sample project) that compete with the mwc-card module name, so can it be flattened to mwc-card.js instead of @sample--mwc-card?

Edited
  • reply
  • like

March 20, 2019 at 4:21pm

Thanks for writing that out Colin, I think that makes a lot of sense. I originally liked the concept of a "flat" web_modules directory as a way to keep it simple, but obviously having a unique set of file naming rules has turned out to have the opposite affect.

  • reply
  • like
Show more messages