googlearchive/polyup

A helpful assistant for migrating from Polymer v0.5 to 1.0. Does many of the boring mechanical parts for you.

polyup's Issues

Ace editor? - "There's an element for that"

Just a note after the PolymerSummit 2015
There is an element for ace editor
https://github.com/Juicy/juicy-ace-editor
http://juicy.github.io/juicy-ace-editor/kitchen-sink.html
Once I'll get back from Summit, I could make a PR with it.

Failing with cryptic error message

Maybe I'm being too picky, but it would help if polyup could at least point at the line in which it couldn't handle something.

Running polyup on https://github.com/stevenrskelton/sortable-table yields the following output:

polyup sortable-table.html 
Error attempting to upgrade sortable-table.html



/home/user/.npm-packages/lib/node_modules/polyup/dist/node_main.js:111
  throw e;
        ^
Error: Line 1: Unexpected identifier
    at throwError (/home/user/.npm-packages/lib/node_modules/polyup/node_modules/espree/espree.js:2070:17)
    at throwUnexpected (/home/user/.npm-packages/lib/node_modules/polyup/node_modules/espree/espree.js:2115:9)
    at consumeSemicolon (/home/user/.npm-packages/lib/node_modules/polyup/node_modules/espree/espree.js:2214:9)
    at parseStatement (/home/user/.npm-packages/lib/node_modules/polyup/node_modules/espree/espree.js:4361:5)
    at parseSourceElement (/home/user/.npm-packages/lib/node_modules/polyup/node_modules/espree/espree.js:5187:16)
    at parseSourceElements (/home/user/.npm-packages/lib/node_modules/polyup/node_modules/espree/espree.js:5220:25)
    at parseProgram (/home/user/.npm-packages/lib/node_modules/polyup/node_modules/espree/espree.js:5240:12)
    at Object.parse (/home/user/.npm-packages/lib/node_modules/polyup/node_modules/espree/espree.js:5483:19)
    at matchFirstExpression (/home/user/.npm-packages/lib/node_modules/polyup/dist/upgrade_html.js:669:46)
    at Page.matchExpressions (/home/user/.npm-packages/lib/node_modules/polyup/dist/upgrade_html.js:698:23)

PolyUp should recognize core-drawer-toggle and convert to paper-drawer-toggle

The core-drawer-toggle is handy in a core-drawer-panel, and should be converted accordingly to paper-drawer-toggle in Polymer 1.0.

When there are no changes to be made, leave the source byte for byte identical.

Polyup crashes inserting warning about being unable to infer the components dir.

I am hoping there is maybe something I am missing to make this more meaningful? I have an html file (several actually) that if I run polyup against and I get this output

polyup --overwrite main.html
Error attempting to upgrade main.html


/usr/local/lib/node_modules/polyup/lib/node_main.js:55
  throw e;
        ^
TypeError: Cannot read property 'previousSibling' of undefined
    at insertHtmlCommentBefore (/usr/local/lib/node_modules/polyup/lib/upgrade_html.js:580:11)
    at addHtmlImport (/usr/local/lib/node_modules/polyup/lib/upgrade_html.js:685:5)
    at upgradeGlobalCss (/usr/local/lib/node_modules/polyup/lib/upgrade_html.js:612:5)
    at upgradeHtml (/usr/local/lib/node_modules/polyup/lib/upgrade_html.js:47:3)
    at Object.<anonymous> (/usr/local/lib/node_modules/polyup/lib/node_main.js:52:15)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:501:10)

event names are not upgraded

when a core-signals element is found, it is correctly converted to iron-signals, but the on-core-signal-??? is left as on-core-signal-???

polyup should migrate docs for properties

e.g.

Polymer('x-elem', {
  /** The value that we care about. */
  value: 0
});

should become

Polymer({
  is: 'x-elem',
  properties: {
    /** The value that we care about */
    value: {
      type: Number,
      value: 0
    }
  }
})

0.5 attribute?="" bindings get transformed into invalid computed property names

Running the online tool (http://polymerlabs.github.io/polyup/),

0.5 code:

<div hidden?="{{!fetchError}}">

polyup 1.0 transformed code:

<div hidden$="{{computeHidden?(fetchError)}}">

The computeHidden?() that gets created on the prototype is an invalid JS method name, and it throws.

Support template strings in components

Got the following stack trace when upgrading a component with an ES6 template string (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/template_strings)

Error: Line 20: Unexpected token ILLEGAL
at throwError (polyup/node_modules/espree/espree.js:2075:17)
at scanPunctuator (polyup/node_modules/espree/espree.js:646:5)
at advance (polyup/node_modules/espree/espree.js:1424:12)
at lex (polyup/node_modules/espree/espree.js:1478:74)
at parseAssignmentExpression (polyup/node_modules/espree/espree.js:3561:17)
at parseExpression (polyup/node_modules/espree/espree.js:3573:16)
at parseStatement (polyup/node_modules/espree/espree.js:4339:12)
at parseSourceElement (polyup/node_modules/espree/espree.js:5181:16)
at parseFunctionSourceElements (polyup/node_modules/espree/espree.js:4419:25)
at parseFunctionExpression (polyup/node_modules/espree/espree.js:4667:12)

I believe espree supports template strings via a config option, but they are default disabled.

Should rename import for core-animated-pages to neon-animation/neon-animated-pages.html

polyup generates invalid code when there are multiple complex expressions assigned to the same attribute name

<div title='{{1 + 1}}'></div>
<div title='{{2 + 2}}'></div>

Becomes

<div title='{{computeTitle()}}'></div>
<div title='{{computeTitle()}}'></div>

With multiple competing definitions for computeTitle. Need to generate unique names for each computed function.

remove '-' from name of compute functions

If the attritute name has a '-' in it, eg 'data-tile', then polyup names the compute function, 'computeData-tile'. A solution is to simply quote the property name in the element's prototype, but that's a bit poor, imo - better to simply remove the '-' and perhaps capitalise the following letter too, ie computeDataTile.

Case in point:

https://github.com/01org/nlpljs/blob/mw-polymer-1.0-upgrade/example-app/app/content_push/cp-display.html#L230

    <div id="preresults" class="fill vbox"
         data-show="{{state === 'preresults'}}">

comes out as :

    <div id="preresults" class="fill vbox"
         data-show$="{{computeData-show(state)}}">
...
        computeData-show: function (state) {
          return state === 'preresults';
        },

which isn't valid javascript.

Migrate CSS to use Polymer 1.1's style modules

Support updating <template bind='expr as value'>

Note that this can apparently be combined with a <template if='...'> a la <template if='...' bind='...'>

Don't create a computed function just for a negation

This isn't necessary. Docs: https://www.polymer-project.org/1.0/docs/devguide/data-binding.html#expressions-in-binding-annotations

Upgrade class='{{...}}' expressions properly.

Specifically we'll need to turn that into class$='...'

Upgrade 0.5 style one time data bindings [[likeThis]]

Default host attributes that are listeners get transformed incorrectly

0.5 code:

<polymer-element name="chromedash-featurelist" on-scroll="{{onScrollList}}" on-keyup="{{onKeyUp}}">

gets transformed into:

hostAttributes: {
    on-scroll: '{{onScrollList}}',
    on-keyup: '{{onKeyUp}}',
  },

This should instead be under listeners and from {{}}.

Bindings on data-* attributes should be transformed to $=

0.5:

<div data-version="{{prop}}">

needs to be:

<div data-version$="{{prop}}">

indentation error; comment at top of file cause first line to be messed up

Here is a simple polymer element :

<link rel="import" href="../bower_components/some-element.html">

<polymer-element name="my-element">
  <template>
    <style>
    </style>
  </template>
  <script>
    Polymer({});
  </script>
</polymer-element>

which results in :

<link rel="import" href="../bower_components/some-element.html">

<dom-module id="my-element">
  <style>
    </style>
  <template>
  </template>
</dom-module>
<script>
  Polymer({ is: 'my-element' });
</script>

1. Note that error in indentation for the closing style tag

More significantly, if you add a comment at the top of the file:

<!-- -->
<link rel="import" href="../bower_components/some-element.html">

<polymer-element name="my-element">
  <template>
    <style>
    </style>
  </template>
  <script>
    Polymer({});
  </script>
</polymer-element>

you get :

<!-- --><html><head><link rel="import" href="../bower_components/some-element.html">

<dom-module id="my-element">
  <style>
    </style>
  <template>
  </template>
</dom-module>
<script>
  Polymer({ is: 'my-element' });
</script>

2. Notice the mess that is made of the first line, including 'joinin' it with the second line, and <html><head> is added.

In 1.0 'extends' is a property on the declaration, never an attribute.

Upgrade assignments to use this.set

Move HTML comment children from <polymer-element> to just above <dom-module>

Strip out the ="" from attribute="" in HTML output

Currently

<div hidden></div>

is output as

<div hidden=""></div>

We should strip out that ="" somehow.

Upgrade custom filters

i.e. as documented here: https://www.polymer-project.org/0.5/docs/polymer/expressions.html#custom-filters

Move element stylesheet's outside of <template> and add necessary attributes

In 0.5, stylesheets were supported inside the element's <template>. In 1.0, this needs to be moved outside of the <template> and rel="import" type="css" instead of type="stylesheet"

<link rel="import" type="css" href="file.css">

Add a --recursive option for upgrading all of the html files in a directory

Allow setting a webserver root.

Our HTML import paths are absolute, not relative. A command line option that functions like "-p" on vulcanize would be great:

-p |--abspath : use as the "webserver root", make all adjusted urls absolute

Don't create duplicate computed function declarations

<div title='{{2 + 2}}'></div>
<div title='{{2 + 2}}'></div>

should become

<div title="{{computeTitle}}"></div>
<div title="{{computeTitle}}"></div>

...

computeTitle: function() {
  return 2 + 2;
}

Rather than creating computeTitle and computeTitle2, but only because their definitions are exactly the same.

use --layout-fit instead of reimplementing it

I'm not sure why polyup makes style rules for the layout attributes at all (I'd love to know)[0], but it does this for most of the layouts, but not for 'fit', even though the rule is identical :

https://github.com/PolymerElements/iron-flex-layout/blob/master/iron-flex-layout.html#L271

    --layout-fit: {
      position: absolute;
      top: 0;
      right: 0;
      bottom: 0;
      left: 0;
    };

This is what Polyup adds :

      [fit] {
        position: absolute;
        top: 0;
        right: 0;
        bottom: 0;
        left: 0;
      }

The other layout attributes are replaced like this:

      [layout][horizontal] {
        @apply(--layout-horizontal);
      }

so, I would have expected :

      [fit] {
        @apply(--layout-fit);
      }

So :

1. is there a reason for not using classes as described in the migration guide, and,
2. is there a reason for not using --layout-fit?

Thanks.

polyup duplicates comments

Example:

<polymer-element name="example-element">
  <script>
    Polymer('example-element', {
      ready: function() {
        var foo = 1;

        /* This is an example block comment which is intended
         * to refer to the block of code below. */
        var bar = 2;

        // This is a line comment which refers to the block below.
        var baz = 3;
      }  
    });
  </script>
</polymer-element>

Gets converted to:

<dom-module id="example-element">
</dom-module>
<script>
  Polymer({
    is: 'example-element',
    ready: function () {
      var foo = 1;  /* This is an example block comment which is intended
                     * to refer to the block of code below. */
      /* This is an example block comment which is intended
       * to refer to the block of code below. */
      var bar = 2;  // This is a line comment which refers to the block below.
      // This is a line comment which refers to the block below.
      var baz = 3;
    }
  });
</script>

polyup removes backslashes from regexp string.

Polyup makes a complete mess of comments, but they're still comments and so are quite inert.

However, I consider the following change to be more worrisome - it seems that polyup has removed backslashes from regular expressions, which surely completely changes their effect :

$ git diff master cp-formatter.js 
diff --git a/example-app/app/content_push/cp-formatter.js b/example-app/app/content_push/cp-formatter.js
index 916c4b2..b3667b7 100644
--- a/example-app/app/content_push/cp-formatter.js
+++ b/example-app/app/content_push/cp-formatter.js
@@ -27,10 +27,10 @@

 (function () {
   /* regexp for HTML tags */
-  var HTML_TAG_REGEX = new RegExp('<\/?[^<>]+?\/?>', 'gm');
+  var HTML_TAG_REGEX = new RegExp('</?[^<>]+?/?>', 'gm');

   /* regexp to retrieve the domain from a URL */
-  var DOMAIN_REGEX = new RegExp('http[s]?:\/\/([^\/]+)\/');
+  var DOMAIN_REGEX = new RegExp('http[s]?://([^/]+)/');

   var CpFormatter = {
     /* clean HTML tags out of text */

Any thoughts on this? Perhaps there is some validity to removing them that I'm not seeing...

Computed attributes being incorrectly generated

Vague bug, but I encountered an issue where it seemed like a computed function was written to the wrong attribute on an element with multiple bound attributes (perhaps because of attrName?='x' syntax?).

Need to track this down further.

Minimize upgrade diff by adding option to just reformat code first

I am attempting to update this app :

https://github.com/01org/nlpljs/tree/master/example-app

it has 32 polymer elements :

https://github.com/01org/nlpljs/tree/master/example-app/app/content_push

So, the upgrade effort is significant. Polyup has helped, but it makes a lot of unnecessary diffs that obfuscate the real changes.

It occurred to me that it might be a worthwhile step to preprocess the code into the 'expected' coding style before running polyup, so that the real changes can be seen more clearly.

Does polyup presume certain coding style? Would it help to convert the code into that style prior to using polyup, and is there a tool to do this?

Support filter syntax in expressions

<!-- comment section --> at start of file converted to <!-- comment section --><html><head>

Comment sections at the start of the component .html file are not handled properly.
e.g.
<!--
copyright notice ...
-->
<link href="../polymer/polymer.html" rel="import">

is converted to
<!--
copyright notice ...
--><html><head><link href="../polymer/polymer.html" rel="import">

I know that in response to #25 you said

"It's expected that the output of polyup will need some polishing in almost all cases."

, but given that copyright notices are common at the start of the file it would be really nice if we didn't have to remove the injected <html><head> from ALL of our polyup'd component files.

Upgrade expressions that use tokenList

Don't crash when a property name ends with Changed

allow polyup to be re-run on already polup'd files?

I started my upgrade process quite some time ago, and you keep fixing bugs... ;)

Since I am working through all the files, trying to fix the bugs manually, as well as the more cosmetic aspects that change, it isn't too desirable to start again from scratch; but I'd equally like to be able to use the newer fixed versions of polyup.

It does sound very difficult, but I wonder if there might be a way to allow polyup to take an already polyup'd file as input and only change the bits that haven't been done.

Yeah, I thought not, but, if you don't ask...

Perhaps there is some way to actually validate a polymer element? Linting (inlinelint) helps, but it doesn't catch things that interface between html and javascript - there are lots of javascript function and property names that are put as attribute values in html. It'd be great to be able to have a polylint utility...different to polyup, for sure, but somehow seems quite similar too.

<template repeat> conversion not working

<template repeat='{{groups as group}}'>
  <p>test</p>
</template>

Fails with Line 1: Unexpected identifier both using the tool and on your interactive version.

Thanks for a great tool that is saving us tons of time :)

Support document.createElement and other imperative code transforms

Imperative 0.5 code:

var xhr = document.createElement('core-ajax');

should transform into:

var xhr = document.createElement('iron-ajax');

Add option to specify URL path to components dir

We otherwise infer this for the sake of inserting new HTML imports.

element-mapping.js: Replace paper-dropdown with paper-menu-button

Currently, paper-dropdown is replaced with iron-dropdown, which needs non trivial manual changes to get to work properly.

A better approach would be to replace paper-dropdown with paper-menu-button
https://elements.polymer-project.org/elements/paper-menu-button?view=demo:demo/index.html

object[key] expressions miss dependency on key identifier

<div title='{{obj[key]}}'></div>

should become

<div title="{{computeTitle(obj, key)}}"></div>

...

computeTitle: function(obj, key) {
  return obj[key];
}

Elements events bind

the migration doesn't change the events binding in the elements, all the on-[event]-[fired] still have the "{{[event-handler]}}" instead of "[event-handler]"

In AfterUserGuide.md and README.md, web-components-ready should be WebComponentsReady

AfterUserGuide.md Line 85:
window.addEventListener('web-components-ready', function() { ... });
should be
window.addEventListener('WebComponentsReady', function() { ... });

README.md Line 148:
Replace addEventListener('polymer-ready', ...) with addEventListener('web-components-ready', ...)
should be
Replace addEventListener('polymer-ready', ...) with addEventListener('WebComponentsReady', ...)

see https://www.polymer-project.org/1.0/docs/migration.html#polymer-ready

When I tried it with Polymer 1.1.2, the WebComponentsReady event fired, but web-components-ready did not fire.

Declarative event handlers need to remove {{}}

In 0.5, I had on-tap="{{toggle}}" which was preserved. Instead, this should be: on-tap="toggle" in 1.0.

Add flag to pass in filenames to leave unmodified

I ran polyup against this project https://github.com/christopheclc/polymer-date-picker/ as a test, and it behaves a tad oddly.

polyup polymer-date-picker.html

1. if no --overwrite is given it inlines moment.min.js as well...
2. if --overwrite is given it aborts because of moment.min.js being outside CWD (understandable precaution but, really it should ignore it right?

invalid js output: hostAttributes: { touch-action: 'none' }

Easy enough to fix: hostAttributes: { 'touch-action': 'none' }

Name computed functions with a leading underscore

To mark them as private (usually what's intended)