Skip to content
This repository was archived by the owner on Oct 26, 2021. It is now read-only.

Updates to get the tests passing again.#36

Closed
bicknellr wants to merge 10 commits into
masterfrom
fix-tests
Closed

Updates to get the tests passing again.#36
bicknellr wants to merge 10 commits into
masterfrom
fix-tests

Conversation

@bicknellr

@bicknellr bicknellr commented Dec 14, 2016

Copy link
Copy Markdown
Contributor
  • Stops the native shim and its tests from running if window.customElements does not exist.
  • Tests forcing the polyfill now no longer expect customElements to exist.
  • Tests now import a Promise polyfill.
  • Updated WCT to 6.0.0-prerelease.3 to get ES2015->ES5 compilation during tests. (6.0.0-prerelease.4 seems to have a bug that prevents (at least) local testing.)
    • Removed use of String#endsWith, which doesn't get compiled during testing...
  • npm install now causes bower install.
  • A test checking that the HTMLElement#constructor descriptor has both writable and configurable true was changed to check that these values match the native descriptor's values.

@bicknellr bicknellr changed the title Prevent tests from assuming that customElements exists. WIP: Prevent tests from assuming that customElements exists. Dec 14, 2016
@bicknellr

Copy link
Copy Markdown
Contributor Author

I'm still trying to figure out why wct --sauce .. isn't working for me, so I can't yet confirm that this is working everywhere.

Comment thread src/native-shim.js
'use strict';

// Do nothing if `customElements` does not exist.
if (!window.customElements) return;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should check for polyfilled also

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't that also a case where you wouldn't want the native shim to run?

Comment thread tests/html/imports.html Outdated
<head>
<title>Custom Elements: imports integration</title>
<script>
window.customElements = window.customElements || {};

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

window.customElements = window.customElements || {forcePolyfill: true};

?

Only cause this snippet might be what we recommend to users...

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we do that, then forcePolyfill doesn't get added in the case that customElements already exists (native).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about
(window.customElements = window.customElements || {}).forcePolyfill = true; ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I went ahead and changed to this.)

@bicknellr bicknellr changed the title WIP: Prevent tests from assuming that customElements exists. Prevent tests from assuming that customElements exists. Dec 19, 2016
… match native, rather than being specifically true.

They should be true per spec but it seems like Safari sets writable to false.
@bicknellr bicknellr changed the title Prevent tests from assuming that customElements exists. Updates to get the tests passing again. Dec 19, 2016
Comment thread tests/js/patching.js Outdated
@@ -13,9 +13,11 @@ suite('patching', function() {
suite('HTMLElement', function () {

test('constructor is configurable and writable', function() {

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test doesn't really make sense. On this line, the new HTMLElement.prototype is set to the old one, so the descriptor is exactly the same. So, I'm going to remove this.

@bicknellr

Copy link
Copy Markdown
Contributor Author

@justinfagnani Aside from a couple of unsupported browsers erroring out completely in WCT, I think this is ready for review.

Comment thread package.json
"url": "https://github.com/webcomponents/custom-elements/issues"
},
"scripts": {
"install": "$(npm bin)/bower install",

@internettrans internettrans Jan 10, 2017

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This causes things to break for me if I npm install @webcomponents/custom-elements (I tried installing your forked version of custom-elements). Since bower is a devDependency, it is not installed but the install script still tries to use it.

What is the purpose of this install script? When somebody is npm installing this project, they don't need the bower_components, do they?

@bicknellr bicknellr closed this Feb 7, 2017
@bicknellr bicknellr deleted the fix-tests branch February 7, 2017 22:03
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants