This script should be self-contained so that a user can just download this one file and not be required to checkout the tools repo.

Polymer allows users to create noscript elements which are elements without any script. When these elements are created, a script is injected. This is not compatible with csp.

In addition, these injected scripts will be ordered incorrectly with respect to the other scripts vulcanize concats.

Before processing scripts, vulcanize should remove the noscript attribute and inject a script inside the polymer-element.

@sjmiles brought up the case where --inline would insert some code that contained </script>, which breaks parsing (the HTML parser makes no assumptions about the contents of scripts, and stops parsing a script at that token).

Polymer now throughs an exception if you try to define a <polymer-element> without loading polymer first. In some cases, the excluded imports may be lower in the flattening.

Shouldn't happen all too often, but still an error condition. Here is the output:

Default output to vulcanized.html in the input directory.

/usr/local/lib/node_modules/vulcanize/lib/vulcan.js:93
  node[0].children[0].data = text;
                           ^
TypeError: Cannot set property 'data' of undefined
    at setTextContent (/usr/local/lib/node_modules/vulcanize/lib/vulcan.js:93:28)
    at null.<anonymous> (/usr/local/lib/node_modules/vulcanize/lib/vulcan.js:119:5)
    at exports.each (/usr/local/lib/node_modules/vulcanize/node_modules/cheerio/lib/api/traversing.js:226:24)
    at resolvePaths (/usr/local/lib/node_modules/vulcanize/lib/vulcan.js:117:10)
    at concat (/usr/local/lib/node_modules/vulcanize/lib/vulcan.js:188:5)
    at null.<anonymous> (/usr/local/lib/node_modules/vulcanize/lib/vulcan.js:205:7)
    at exports.each (/usr/local/lib/node_modules/vulcanize/node_modules/cheerio/lib/api/traversing.js:226:24)
    at processImports (/usr/local/lib/node_modules/vulcanize/lib/vulcan.js:198:14)
    at Object.handleMainDocument [as processDocument] (/usr/local/lib/node_modules/vulcanize/lib/vulcan.js:280:3)
    at Object.<anonymous> (/usr/local/lib/node_modules/vulcanize/bin/vulcanize:89:10)

Would you consider a pull request rewriting these shell scripts in node so they can be more easily parallelized? pull-all.sh is terribly slow and doing nested async in bash is clunky.

Hi there,

My <a href="mailto:[email protected]">[email protected]</a> gets rewritten as <a href="path/to/component/mailto:[email protected]">[email protected]</a>

Cheers,

Jun

For the polymer web site, it would be nice to be able to generate a set of vulcanized files, each consolidating a set of vulcanized files, something like this:

base.html includes a.html, b.html
more-stuff.html includes c.html, d.html which depends on a.html
extra-stuff.html includes e.html, which depends on b.html and d.html

It would be good to load a minimal set for the landing page, and load other stuff as needed. However, since it's a one-page app, all the imports need to work together.

I know doing this in an automated fashion would be complicated. My simplistic proposal for a manual process is something like this:

vulcanize -o base.html base-imports.html --map base.map

Where base.map contains a list of dependencies included in base.html

Then:

vulcanize -o more-stuff.html more-stuff-imports.html --depends-on base.html --map more-stuff.map

Where any reference to an import in base.map is replaced with an import of base.html.

Feel free to propose a more elegant mechanism ;-).

This could also be grunt-vulcanize but I suspect it's here. The excludes option isn't excluding according to my regex:

        excludes: {
          imports: [
            "polymer.html$"
          ]
        },
        strip: false,
        csp: false
      }
    },

Furthermore, it's leaving in polymer.html imports and doing crazy things with paths:

<link rel="import" href="../components/components/components/components/components/polymer/polymer.html">

I'm trying to use vulcanize on Pica, using:

$ vulcanize --strip --inline index.html

But I'm still getting all the HTML comments in the vulcanized.html result. Also tried without --inline, and with --csp --inline. Did this break at some point?

Wouldn't it be cool if the vulcanizer could generate a test suite for the element tree as part of the vulcanizing process?

Hey,

Am a bit stuck. I am using lots of polymer templates to allow me to not have to do server side includes. Works really well.

But when i vulcanize it, it moves the platform and polymer script loaders files to the end, and so everything else stops working.

here is the gist:
https://gist.github.com/bmadmin/9153069

The intent is so that people (non coders) that want to make a new .html pages have the least amount of code to boilerplate in.

.

I would like to use Vulcanize, but it's hard to integrate it since it handles it's own file reading/writing, and I have the files already in buffers and want to write them myself. I understand you need the paths to be able to resolve relative paths, but I would be handy if it was possible to supply additional options inputSrc string and outputSrc callback function or string depending on whether you do anything async (I haven't looked) which would use that instead of using fs.read/write.

You pretty never want a bom in the middle of a concatenated file. This can cause confusing bugs. It'd be great if vulcanizer could eliminate these when concatenating.

I just ran into this when trying to implement the ES6 module loader polyfill (https://github.com/ModuleLoader/es6-module-loader) in a project alongside Polymer.

window.Loader is currently in the ES6 module specification as the native loader global. Since Polymer is aiming to sit in the same sort of timescale as these implementations, ideally it would use another global name for the loader.

This checkout works: baea0e1

Latest one just exits with no error.

We're using <script type="application/fbp"> for inline FBP language graphs in NoFlo UI. Currently vulcanization moves them to the built .js file, which obviously breaks everything.

Example HTML file: https://github.com/noflo/noflo-ui/blob/the-graph/index.html

When I try the example in http://www.polymer-project.org/articles/concatenating-web-components.html with vulcanize 0.2.4, the --csp option results in a build.html file without a <script src="build.js"></script> tag to load the externalized javascript.

Why?

Vulcanize has accumulated a lot of cruft its humble beginnings as a one-off script.
Since usage of vulcanize is increasing, its time to pay down that technical debt with some good factoring.

Plan of Action

• Keep same functionality
• Be async friendly
• Support staged or one-at-a-time builds
• Plug and play other tools (uglify, cssmin, svgo)?
• Actually have tests
• Reuse path code from polymer where possible
• Don't be tricky, inline directly into the spot dictated by <link rel="import">

Packages that include a "noscript" attribute (like the "core-toolbar" and "core-field" packages) make vulcanize generate an inline "script" tag, even when the --csp option is used. This triggers errors when used in a chrome packaged app (and is obviously a bug since the point of --csp is to get rid of inline scripts).
I don't know if this should be fixed in the packages themselves or in vulcanize, so I just open this issue here.

--strip` tries to be too smart and over optimize styles. I'm not familiar with the node document reader you're using, but it appears deal with the rendered CSSOM rather than rewriting the authored css.

1. It combines style rules that have the same properties. For example, vulcan --strip test.html:

    <style>
     :host([type="platform"]) { background-color: red; }
     :host([type="core"]) { background-color: red; }
     :host([type="elements"]) { background-color: red; }
     </style>
   

   results:

     <style>:host([type=core]),:host([type=elements]),:host([type=platform]){background-color:red}</style>
   

2. It removes necessary polyfill-next-selector:

    <style>
     polyfill-next-selector { content: ':host header'; }
     polyfill-next-selector { content: 'I WIN'; }
    </style>
   

   results:

   <style>polyfill-next-selector{content:'I WIN'}</style>

   It's worth noting that content: ':host header' !important; causes the first rule to persist. So it follows the CSS cascading order.

I was played this codelab,after vulcanize,all the shadow and ripple were missing,and click on the card it throw me an error

Uncaught TypeError: Cannot read property 'setAttribute' of undefined 

Default will be "input", add -r or --rel-to-output

Hi
well everything working fine but after entering cmmand ./tools/bin/pull-all.sh

=== pull core-action-icons ===
=== pull core-ajax ===
=== pull core-bind ===
=== pull core-collapse ===
=== pull core-component-page ===
=== pull core-component-page-d
(continue)

then my internet connection automatic disconnect-connect due to high load of remote connection, and then i get below error

Reason:  ssh: Could not resolve hostname github.com: Name or service not known
fatal: Could not read from remote repository.

So any other solution to install polymer tools?

Are there any plans to support source maps in Vulcanize? Like any other transformation tool, it'd be really valuable to be able to trace code back to the original source.

I'm not aware of any other tool creating source maps for HTML yet (as opposed to the usual CSS/JS), so the spec might need some adapting in terms of how the source map is referenced from a comment at the end of the generated source file.

Vulcanize nests <svg> content incorrectly.

<head>
   <title>Cannot vulcanize me</title>
</head>
<body>
   <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 630 630" fill="#fff" width="630" height="630">
      <rect x="0" y="0" width="630" height="630" fill="#3c790a"/>
      <path d="m212 497c11 17 20 31 40 31 19 0 32-8 32-37v-201h59v202c0 61-36 89-88 89-47 0-75-25-89-54M423 492c13 21 29 36 58 36 25 0 40-12 40-29 0-20-16-27-43-39l-15-6c-43-18-71-41-71-89 0-44 34-78 87-78 38 0 65 13 84 47l-46 30c-10-18-21-25-38-25-17 0-28 11-28 25 0 18 11 25 36 36l15 6c50 22 79 44 79 93 0 53-42 82-98 82-55 0-91-26-108-60"/>
   </svg>
</body>

Becomes

<title>Cannot vulcanize me</title>

<svg xmlns="http://www.w3.org/2000/svg" viewbox="0 0 630 630" fill="#fff" width="630" height="630">
    <rect x="0" y="0" width="630" height="630" fill="#3c790a">
    <path d="m212 497c11 17 20 31 40 31 19 0 32-8 32-37v-201h59v202c0 61-36 89-88 89-47 0-75-25-89-54M423 492c13 21 29 36 58 36 25 0 40-12 40-29 0-20-16-27-43-39l-15-6c-43-18-71-41-71-89 0-44 34-78 87-78 38 0 65 13 84 47l-46 30c-10-18-21-25-38-25-17 0-28 11-28 25 0 18 11 25 36 36l15 6c50 22 79 44 79 93 0 53-42 82-98 82-55 0-91-26-108-60">
</path></rect></svg>

The <path> should not be contained inside the ```

vulcanize --inline allows us to inline all scripts into the main HTML file. However, --csp leaves existing scripts alone, and only puts inline scripts into the output JS file. Perhaps --inline --csp should inline all scripts into the single csp-compatible JS file.

buildbot
apps
chrome-app-seed
polymer-chrome-app

In the interest of having a locally custom version of pull-all, the autoupdate portion has been disabled.

Instead of auto-exec'ing a copy of pull-all in tools, the script should warn if the tools checkout has a more recent copy.

I want to know is there pull-all.bat script so I can run it on windows 8.

Hi!

Reading the docs:
"If no output is specified, vulcanized.html is used by default."

Are there any plans on changing this to the standard behaviour of sending the output to stdout instead? I can't see the benefit of creating a non-standard file instead.

At the moment it's hard to build vulcanize into a existing build system without it.

Thanks,
Josua

Would it be possible to have an option to include all html imports as strings in a .js file?

I'm asking because I'm teaching an HTML/JS course and we're using jsbin. I can't load custom elements from github.io there because:

XMLHttpRequest cannot load http://forresto.github.io/polymer-pixi-box2d/build/polymer-pixi-box2d.html. Origin http://run.jsbin.com is not allowed by Access-Control-Allow-Origin.

http://jsbin.com/ARulIBoX/3/edit

(We ended up using Codio and forking the project, which worked.)

Seems like if one HTML test fails, it causes other tests to report false failures.

core-animated-pages (bc70b6e) repository doesn't exists.

Error when cloning with pull-all.sh:

FAILED REPOS
Repo:  Polymer/core-animated-pages.git
Folder:  components/core-animated-pages
Operation:  clone
Reason:  Cloning into 'core-animated-pages'...

ERROR: Repository not found.

fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I ran into an issue trying to update a component and wanted to get feedback here before submitting a PR. The flow was:

1. Make a change in master, push it
2. run gp.sh
3. The change wasn't reflected to the gh-pages branch Bower's cache was pulling the previous commit.

Should we add bower cache clean as part of the script? Will this present other problems?

@addyosmani @azakus

It's good that we have a warning if a repo cannot be pulled but it's bad that the checkout process stops at that point. Since checking out can take a bit, it's common to not watch the process. To come back and have it interrupted is not good.

Instead, I suggest we have it continue to the end and then give a summary of what happened.

Evaluate some sort of --remote option that will grab script and stylesheets with absolute, remote URLs.

I tried to use vulcanize to inline all my scripts, and then --csp them back out, to work around #30, but the csp step broke platform/platform.js.

Could use uglify and a css minifier to strip comments.

looks like clean-css is the culprit as far as i can tell.

the last selector is the only one that remains which leads me to believe that they are doing some sort of object hashing internally with the selectors that gets overwritten by each 'duplicate' selector

https://github.com/Polymer/vulcanize/blob/master/CONTRIBUTING.md

Link leads to a 404 ..

This option would allow for '/root/' style absolute paths to be vulcanized.