search

google / ioweb2015

I/O Web App 2015
https://events.google.com/io2015/
Apache License 2.0
687 stars 122 forks source link

missing loader.js seems to prevent template rendering? #1525

Closed x1ddos closed 9 years ago

x1ddos commented 9 years ago

For some reason, this looks to be the cause of nothing being rendered:

screen shot 2015-06-15 at 11 15 20 am

there seems to be nothing except #document-fragment:

screen shot 2015-06-15 at 11 18 30 am

@devnook tried disabling experiment and it all starts working as normal.

x1ddos commented 9 years ago

@ebidel @tdreyno where does the loader.js come from and why we don't see it in staging? neither in prod...

x1ddos commented 9 years ago

@devnook and me think that if you run gulp build-experiment at least once beforehand, then gulp serve:gae should start working but gulp build-experiment is broken :( #1526

x1ddos commented 9 years ago

I guess the main queston of this bug is why would it prevent Polymer from stamping templates and proceed with its normal course?

Instead, it throws the error in elements.js on var mastheadMeta = masthead.querySelector('.masthead-meta'); as seen in the screenshot - there are no elements in the DOM, only #document-fragment.

ebidel commented 9 years ago

I just ran gulp build-experiment on my existing setup and it worked from master. Be sure to npm install to get the latest promise polyfill. I updated it.

I can try and dig through this more when I get to the office.

x1ddos commented 9 years ago

I did run "npm install" before "gulp build-experiment". Can you try fresh, starting from "git clone ..."?

On 15 June 2015 at 16:27, Eric Bidelman notifications@github.com wrote:

I just ran gulp build-experiment on my existing setup and it worked from master. Be sure to npm install to get the latest promise polyfill. I updated it.

I can try and dig through this more when I get to the office.

— Reply to this email directly or view it on GitHub https://github.com/GoogleChrome/ioweb2015/issues/1525#issuecomment-112109194 .

tdreyno commented 9 years ago

Yes, loader.js is the preloaded for the experiment. It should be generated and copied by gulp build-experiment if that task succeeds.

That code will probably never change again, so, maybe commit the working result to GH once you get it functioning with your new dependencies.

ebidel commented 9 years ago

When we track down what deps work, let's lock them in. I don't trust everyone's knowledge of semver breaking changes :)

tdreyno commented 9 years ago

npm shrinkwrap is as good as it gets on node... or committing node_modules.

x1ddos commented 9 years ago

committing node_modules is a ton of megs :-O On 15 Jun 2015 5:59 pm, "Thomas Reynolds" notifications@github.com wrote:

npm shrinkwrap is as good as it gets on node... or committing node_modules .

— Reply to this email directly or view it on GitHub https://github.com/GoogleChrome/ioweb2015/issues/1525#issuecomment-112137375 .

ebidel commented 9 years ago

Yea we have to avoid checking in code that isn't ours.

On Mon, Jun 15, 2015, 10:00 AM alex notifications@github.com wrote:

committing node_modules is a ton of megs :-O On 15 Jun 2015 5:59 pm, "Thomas Reynolds" notifications@github.com wrote:

npm shrinkwrap is as good as it gets on node... or committing node_modules .

— Reply to this email directly or view it on GitHub < https://github.com/GoogleChrome/ioweb2015/issues/1525#issuecomment-112137375

.

— Reply to this email directly or view it on GitHub https://github.com/GoogleChrome/ioweb2015/issues/1525#issuecomment-112138228 .