The experimental support for Firefox in Puppeteer has been just announced: https://github.com/GoogleChrome/puppeteer/tree/master/experimental/puppeteer-firefox#readme

From now on, it is possible to run visual or e2e tests in 2 browsers, making more sense to use Puppeteer - especially because you can run both Chrome and Firefox locally in Travis or CircleCI, without using cloud automation like SauceLabs which takes much more time.

I'm planning to investigate this and will report my findings here. Feel free to join.

If you configure webpack to use another folder as the context folder, e.g.

module.exports = {
  context: path.resolve(__dirname, 'src'),

then import-meta-url-loader.js won't work as it assumes this.context contains this.rootContext: this.context.indexOf(this.rootContext), which will return -1 in this case, e.g.

context: /path/to/my-project/node_modules/@fooloomanzoo/input-picker-pattern
rootContext: /path/to/my-project/src

so far we have:

Just now visiting open-wc.org site for the first time. U guys are killing it! Amazing stuff, and IMO totally on target. many thanks

petecarapetyan

I used open-wc to get testing working, was sooo helpful, works like a charm

Ikira

https://github.com/nodecg/express-transform-bare-module-specifiers

So in regard to the earlier discussion with @petecarapetyan on slack, I think we have some things that require some more explanation/argumentation. I think it would be good to have an 'Our philosophy' page. I made a little draft of what could be on that page, with a couple of points that are good to cover, PR here: #141 (very much a draft to iterate on, phrasing/wording is not perfect etc)

Furthermore, per category, I think it's good to write some clarification/argumentation on why we made some of the choices that we did:

Developing:
	- Why lit-html/lit-element over Hybrids, Gluon, Skate, Svelte, etc etc etc?
		-> developed/maintained by Google

Testing:
	- Why karma over WCT
		-> State some of the WCT painpoints

Demoing:
	- Why Storybook

Publishing:
	- Why Netlify over heroku, firebase, etc

Automating:
	- Why circleci

How did we come to these conclusions, what did we try
Do we have blogs/links to back up our choices?

Would love to get some input from anyone.

Edit: Some of the documentation in the webpack branch lars is really good. Im not saying every section has to be as elaborate, but it really gives me some trust-like feeling, as opposed to simply saying "Here is the tool. Use this.".

defineCE is meant to guarantee a unique custom-element tag name, but this is not always the case.

Consider:

// my-one.test.js
import { My1Class } from './my-two.js';
import { defineCE } from '@open-wc/testing';
defineCE(MyElement1Class) // test-0

// my-two.test.js
import { My2Class } from './my-two.js';
import { defineCE } from '@open-wc/testing';
defineCE(My2Class) // test-0
// Error: Failed to execute 'define' on 'CustomElementRegistry': this name has already been used with this registry

My guess is that this happens because webpack is transpiling to CJS, which makes copies of module state instead of live references, so that when the test runner loads a new file which imports defineCE, the counter is effectively "reset".

I propose that helpers.js do away with the internal name defineCECounter and instead, tag names should just include Date.now()

I'll put together a PR for your consideration.

I'd suggest also adding a note (either in Step 4 above or in Change the default entrypoints) describing what to do if you have more than one HTML/JS entrypoint. I'd have done that but for my complete ignorance (Can indexJS take an array? Or do they need to go to the method described in "Customizing the configuration"? Can you pass a config object with indexHTML/indexJS to createDefaultConfig?)

by @arthurevans via #186

in order to prevent license problems, we should have a CLA Bot.

There are multiple options (ranked by my initial assessment)

1. https://github.com/cla-assistant/cla-assistant (459 ★ nice HP & setup; last commit 1 month ago)
2. https://github.com/ColinEberhardt/cla-bot (17 ★ ok HP, nice setup & nice last commit 20 days ago)
3. https://github.com/clahub/clahub (last commit 2 years ago)
4. https://github.com/clabot/clabot (last commit 4 years ago)

For the CLA itself I would think of something like https://gist.github.com/pjcozzi/4d1ab2166519de7ba41b

When there is a 'splice' diff, for example:

expected: <div a="1" b="2" c="3"></div>
actual: <div a="1" c="3"></div>

you expect the error message to say something like attribute b was removed at path div but in reality it says attribute c was removed at path div.

This is because deep-diff does not see this as one change, but as multiple changes. I don't remember exactly, but I think it reports 'c was removed, b was removed, c was added'. We only take the first change and report that back so we need be a bit smarter about how we parse the response from deep-diff.

I've been working on fixing this in a branch, but didn't get too far yet.

I'm happy to start a PR that adds .d.ts files for editor plugin (i.e. typescript language-server) support.

In our webpack setup we use the fast-async plugin to compile async functions. However that makes it always kick in. Based on: https://caniuse.com/#search=async%20function any browser which supports type="module" supports async functions.

Probably we can remove this transform, but we should properly test this.

I believe some of the helpers are pretty much independent from mocha or any other test related dependency.

For example registerUniqueElement has 0 dependencies.

And many others in helpers.js too.

I have 2 ideas how to improve this.

1. Separate them into 2 packages - testing-helpers with 0 dependencies and testing-mocha-helpers with mocha dependent ones.

2. Make all helpers independent from mocha and provide integration with mocha in the individual package. I'm pretty sure this is technically possible, but I didn't investigate this deep enough to say it will not become more cumbersome. For inspiration take a look at the way how chai handles integration with mocha https://github.com/chaijs/chai/blob/4.2.0/README.md#usage

Result:

If I visit: https://open-wc.org/building/building-webpack.html and scroll down to 'Edit page' upon clicking I'm redirected to an MD with a relative source (../../packages/building-webpack/README.md)

Expectation:

I'm not sure the mechanisms behind the edit page button, it would be easier if a user could click that button and edit that page.

Hi,

I am benchmarking many solutions for testing a simple Web Component created with Stencil.

Did you already test this kind of component with open-wc ?

I have tested :

• webdriver.io : facing shadow Dom querying issues with Selenium + IE11. Seems to be a complicated way to achieve e2e testing for WC.
• Web Component tester : having difficulties with test-fixture package. Seems to not be very stable, the root README is not up to date. Also have difficulties with IE11.

Thanks

I shared https://open-wc.org/ on my company chat and a bunch of people were immediately like "that should be PEACE of mind. Not Piece of mind!!"

Yes, yes, this is pedantic. However, that image really is the first thing people see when they land on the site, and your target audience are a bunch of nerds. As silly as this is, because I think this project is awesome and I want to really give it a shot, I have a need to make sure a spelling error in a meme doesn't cause people to not want to give it a shot.

If you're willing, and swapping out an image isn't too big a deal, could we update it?

In case it would be handy, generated another one that hopefully captures the same intent, but you definitely don't need to use this one:

Thanks!

The docs are not consistent about usage of await before fixture helper:

In test custom element example await is used.
Just below, in test custom class example it does not use await.

This confused me: is necessary or not use await?

After looking into the source i found that fixture is a wrapper around fixtureSync followed to a nextFrame call.

It would be good to newcomers to clarify when await is needed before a fixture call and when not.

As i can see when using a string or a lit-html tagged template as fixture is not needed, but when using a lit-element await is necessary.

I'd like to start work on a style guide to help inform contributions.

A few potential examples of the kinds of guidelines that it should contain:

Use the phrase "Open Web Components" (title case) or "open-wc" (lowercase, in backticks) to refer to the project

Prefer simple English, so that the documentation is as accessible as possible.

All headings should be Title Case e.g. Our Philosophy, not Our philosophy

If list items contain more than two sentences, prefer to use headings.

Thoughts?

with

package-lock.json -diff
yarn.lock -diff

to not show lock files while doing git diff

Currently flush is hardcoded in the fixture helpers implementation and based on the old WCT API.

I don't think it is helpful to pull the legacy of WCT here.

How about making it fully configurable and provide a clear API for that?

If we still want to have out-of-the-box behavior, we can keep setTimeout to delay till next task by default, or just use a simple Promise to delay till next microtask by default.

Let's consider adding prettier to the list of recommendations.

Pros:

• Supports html tagged literals and HTML syntax in general starting from v1.15, see blog post
• Supports css tagged literals being used by lit-css and styled-lit-element

Also worth mentioning:

• eslint-config-prettier
• stylelint-config-prettier
• stylelint-processor-styled-components

There is working example in https://github.com/web-padawan/lit-components

https://bitsrc.io/

the simplest configuration should work

const defaultConfig = require('@open-wc/building-webpack/default-config');

module.exports = defaultConfig();

current result

Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.
 - configuration.entry should be one of these:
   function | object { <key>: non-empty string | [non-empty string] } | non-empty string | [non-empty string]
   -> The entry point(s) of the compilation
...

fix:

// from
const defaultOptions = {
  indexHTML: './index.html',
  indexJS: ['./index.js'],
};

// to
const defaultOptions = {
  indexHTML: './index.html',
  indexJS: './index.js',
};

e.g. we only support a single entry point with the defaultOptions... if you want more you should modify the output or copy the config

It it possible to add support in @open-wc/testing for saucelabs ? via https://github.com/karma-runner/karma-sauce-launcher

just stumbled over it
https://github.com/theintern/intern/

All packages define fixed versions of all dependencies. For example in @open-wc/testing you have "mocha": "5.2.0",

In my project I directly depend on mocha and use semver caret for it. Also some of my dependencies also depend on mocha in a semver manner. But dependency on @open-wc/testing will prevent updates of it and eventually may create a conflict which will lead to impossibility to flatten dependencies.

Why do you have fixed versions atm and can we do it differently?

Just followed this tutorial in an empty folder : https://open-wc.org/testing/

Got this error :

ERROR in ./node_modules/@open-wc/testing-helpers/fixture-no-side-effect.js Module not found: Error: Can't resolve 'lit-html' in '/xxx/node_modules/@open-wc/testing-helpers' @ ./node_modules/@open-wc/testing-helpers/fixture-no-side-effect.js 1:0-42 16:26-40 33:26-40 @ ./node_modules/@open-wc/testing-helpers/fixture.js @ ./node_modules/@open-wc/testing-helpers/index.js @ ./node_modules/@open-wc/testing/index.js @ ./test/test-open-wc-stencil.test.js

Run npm i --save-dev lit-html solve the error.

Assumption:

• Removing comments will reduce load time.
• Using 'uglifyjs-webpack-plugin' will provide a minimal impact to the build time

Self explanatory:

• Comments are helpful, if not necessary to document your code.
• They help developers, but not consumers.

In regards to removing comments in code while building a project you can use the following technique:

npm i -D uglifyjs-webpack-plugin

Add the plugin to your webpack.config.js

const UglifyJsPlugin = require("uglifyjs-webpack-plugin");

Adding it to your config:

  optimization: {
    minimizer: [
      new UglifyJsPlugin({
        uglifyOptions: {
          output: {
            comments: false
          }
        }
      })
    ],
  }`

https://www.npmjs.com/package/showroom

Showroom is an alternative to storybook focusing web-components and supporting the FULL API (i.e. attributes, properties, events, innerHTML and outerHTML) - features that cannot be found on storybook without cumbersome work.

Showroom also supports puppeteer API for automated tests and can be integrated with non-puppeteer test runners.

There should be docs which explain how to contribute. i.e. how to

1. open issues and PRs
2. clone the repo
3. install deps
4. use lerna to orchestrate package deps
5. test changes locally

Also async is not allowed in definition files
https://stackoverflow.com/questions/48448151/how-can-i-add-an-async-function-to-a-type-def-file

I noticed that the docs are published with the help of a tool called vuepress: "Vue-powered Static Site Generator."

Shouldn't we use a web-components view layer?

I've just started with the fixture, and am trying with Polymer 3.0 — is that within scope of the project?

I'm seeing the fixture shadowDom as the below, missing quite a few nodes — does this mean the dom-f/dom-repeat modules are not coming into play in the test, though they are imported by the component under test, and work well in Chrome?

<dom-repeat as="page" style="display: none;"><template is="dom-repeat"></template></dom-repeat>```

Watching sources of @open-wc/testing/index.js, many helpers are exported but not nextFrame. Is it normal ?

export {
  html,
  unsafeStatic,
  triggerBlurFor,
  triggerFocusFor,
  oneEvent,
  isIE,
  defineCE,
  aTimeout,
  litFixture,
  litFixtureSync,
  fixture,
  fixtureSync,
  fixtureCleanup,
} from '@open-wc/testing-helpers/index.js';

We print out slogan and badges in pretty much every markdown file:

Open Web Components provides a set of defaults, recommendations and tools to help facilitate your Web Component. Our recommendations include: developing, linting, testing, tooling, demoing, publishing and automating.

(+ badges)

I see them getting out of sync a few times, and it adds quite a bit of repetition in every file. You need to scroll down to see the actual content, which is a problem on mobile phones.

I'd like to suggest only keeping the Part of Open Web Component Recommendation open-wc part

Currently our testing package relies on modifying globals. This makes tests non self contained and requires some magic to happen before test files are run, either in a parent index.html / index.js and/or requires test tool configuration.

My proposal is to go fully with modules, in your tests use: import chai from '@open-wc/testing which contains all the necessary plugins registered. The same goes for the automatic fixture cleanup, we could register this automatically when you create a fixture or also when you import chai.

timeoutAsync -> waitForMs or waitForTimeout
eventTrigger -> waitForEvent
blurTrigger -> triggerBlur
focusTrigger -> triggerFocus

What do you think? I like waitFor syntax because it reads nicely both with promises and async await:

await waitForMs(100);
await waitForRender();

waitForTimeout(100).then(() => {
  waitForRender().then(() => {
    ...
  });
});

https://github.com/tr1s/tris-webpack-boilerplate

Using:

"@open-wc/testing-helpers@^0.6.2":
  version "0.6.2"
  integrity sha1-sjLqpu6CXLUmB+bMxgaPe3GoyJc=

Pulling in flush as specified here: https://open-wc.org/recommendations/testing-helpers.html#timings

import { litFixture, flush } from "@open-wc/testing-helpers";

Getting red squigglies in vscode, as well as errors indicating flush isn't there. When I click through to source, I see inside index.d.ts:

export { html, unsafeStatic } from './lit-html';
export {
  aTimeout,
  defineCE,
  isIE,
  nextFrame,
  oneEvent,
  triggerBlurFor,
  triggerFocusFor,
} from './helpers';
export { litFixture, litFixtureSync } from './litFixture';
export { fixture, fixtureSync } from './fixture';

export async function aTimeout(ms) {

should just be export function aTimeout(ms) {

See implementation in web-padawan/polymer3-webpack-starter@fb82b28

The results of the config for the starter app (first page load in Chrome 71):

Before (ES5)

Load: 2.00 s (9 requests)

After (ES6)

Load: 1.35 s (7 requests)

e.g. add to readme of all packages
also have a dedicated section on the homepage.

Should contain:

• link to slack #open-wc

any other way we should promote?

possibly for later
do we want a team section where we "publish" our private github/twitter accounts?

The recommended way of using import.meta.url with Polymer seems to be to add a getter for import.meta [1]. Should the webpack import-meta-loader support this use case as well in case you try to load a Polymer3 component?
Or is this more for people not using Polymer?

[1] https://polymer-library.polymer-project.org/3.0/docs/upgrade (see item 6)

Discussion whether we should include the babel decorators plugin by default in our webpack configs.

We need the open-wc headers in our README's, but they clutter up the vuepress docs. We need to somehow filter out the headers.

Or the reverse might be easier, inject the header in a prepublish step.

Discussion whether we should add babel public and private class fields plugin by default to our weback config.

https://github.com/tc39/proposal-class-fields
https://github.com/tc39/proposal-static-class-features/

See issue on karma-webpack.

Solution will be to use karma-webpack@next once codymikol/karma-webpack#380 is merged and and a rc is available.

should be wrapped in a try/catch block to be super safe

like so:

try {
  if (afterEach) {
    afterEach(() => {
      if (cachedWrappers) {
        cachedWrappers.forEach((wrapper) => {
          document.body.removeChild(wrapper);
        });
      }
      cachedWrappers.length = 0; // reset it like this as we can't reassign it
    });
  }
} catch (error) { /* do nothing */ }

• Directory structure
• What to publish

We should create a recommendation what to use as a dev server during development.

I think it's really useful to have a dev server similar to polyserve but with the ability to just read the project's .babelrc.

At the same time if we're using webpack to bundle our app, it becomes really easy to just use the webpack dev server as well. It's mostly just plug and play.

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Preset name not found within published preset config (config:preserveSemverRanges)