1332828 - Using "Date" in macros throws a "Date is not a constructor exception"

Status: VERIFIED FIXED

(developer.mozilla.org Graveyard :: KumaScript, defect)

Description

[Julien G]

What did you do?
================
1. Logged in
2. Tried to refresh a doc status page (e.g. https://developer.mozilla.org/en-US/docs/MDN/Doc_status/JavaScript) 


What happened?
==============
An error message appeared with a stacktrace saying "Date is not a constructor"

What should have happened?
==========================
The macro should have worked as usual.

Is there anything else we should know?
======================================
The doc status pages were working on Friday 20th of January (1PM UTC+1).
I didn't find any significant change in the macros directory that could have caused this. (DocStatus and LocalizationStatusInSection didn't change in the past month and I couldn't find any related/imported macro that was changed either)

Comment 1

[Florian Scholz (Open Web Docs)]

We updated to KumaScript to node v6 yesterday.

In KumaScript dates are created through https://github.com/mozilla/kumascript/blob/master/macros/DekiScript-Date.ejs which might not extend the Date object anymore but overwrites it now? (just a guess, not sure why it breaks now)

I propose to remove DekiScript-Date and to use the original Date object. The original Date object has Date.now and Date.parse. It doesn't have Date.getLocaleDateString which is only used by
https://github.com/mozilla/kumascript/blob/master/macros/DevProgramListUpcomingEvents.ejs (so much win for doing a file search over macros now, or Github code search \o/)

The DevProgramListUpcomingEvents macro is about an ancient DevProgram / the "Connect" page and totally obsolete. It is used on 26 pages. These pages should be archived or deleted.
https://developer.mozilla.org/en-US/search?locale=*&kumascript_macros=DevProgramListUpcomingEvents&topic=none

That said, if I remove "server__autorequire__Date=DekiScript:Date" from https://github.com/mozilla/kuma/blob/master/docker-compose.yml Date is a constructor for me and macros run fine.

Comment 2

[Florian Scholz (Open Web Docs)]

Oh, and as far as I can see the pages affected by this glitch are those using these 3 macros:

1) https://github.com/mozilla/kumascript/blob/master/macros/LocalizationStatusInSection.ejs (851 pages)
2) https://github.com/mozilla/kumascript/blob/master/macros/DocStatus.ejs (53 pages)
Both of these are used just for MDN contributors wanting to see status of pages and localization.

3) https://github.com/mozilla/kumascript/blob/master/macros/DevProgramListUpcomingEvents.ejs (26 pages)
This is just the ancient "Connect" page.

I'm observing if more comes up at https://developer.mozilla.org/en-US/docs/with-errors 

*If you read this today, enjoy your weekend! I don't think breakage of these is major.*

Comment 3

[Florian Scholz (Open Web Docs)]

I filed bug 1333751 which intents to delete the Connect pages (for which I think this weird Date built-in override was created in the first place).

Comment 4

[John Whitlock [:jwhitlock]]

Thanks for your research into this, fscholz.

I've made the suggested changes in:

* https://github.com/mozilla/kumascript/pull/99
* https://github.com/mozilla/kuma/pull/4108

To update the auto-require settings in production, we'll need to modify a couple of files. I'll see if I have the access to do that, and open an IT ticket if I don't.

Comment 5

[John Whitlock [:jwhitlock]]

I can change the files (including adding invalid JSON :( ) and they are applied to staging.  However, the JavaScript status page still won't render on staging, due to a timeout:

https://developer.allizom.org/en-US/docs/MDN/Doc_status/JavaScript

This may be an intermittent failure while the integration tests are running. It may be worth trying them later when USA is still asleep.

Comment 6

[Florian Scholz (Open Web Docs)]

The timeout isn't there when I force-refreshed for a second time.

(side note: I know the Docstatus macros aren't the fastest, and I am willing to move doc status into it's own tool one day. Basically the doc status pages query the Kuma and Bugzilla APIs and display results of the queries. An own tool for this could be much more flexible, faster, and could come with an own caching strategy etc. I even own a domain for this: arewedocumentedyet.com)

Comment 7

[[github robot]]

Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/7253c638186783319a0067e4cf90657f3e3313b2
bug 1332828: Remove DekiWiki:Date from autoload

It is a lesser wrapper on the native Date type, and is shadowing the
native Date type after the node 6.x update.

https://github.com/mozilla/kuma/commit/36704be146b11a793d76549512070bd1cf3ca799
Merge pull request #4108 from jwhitlock/remove_ks_date_1332828

bug 1332828: Remove DekiWiki:Date from autoload

Comment 8

[John Whitlock [:jwhitlock]]

The KumaScript macro changes and the config change have been pushed to production, and the page is happy again:

https://developer.mozilla.org/en-US/docs/MDN/Doc_status/JavaScript

Comment 9

[Julien G]

Thanks! Verified for l10n too.

Comment 10

[[github robot]]

Commit pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/d611e079745f1040318e663c4f6bf4a45b1a6428
Update KumaScript

* Adding learning area links to main HTML sidebar
  https://github.com/mozilla/kumascript/pull/90
* Additions to group and interface data for WebRTC
  https://github.com/mozilla/kumascript/pull/105
* Adding fr strings to the macro
  https://github.com/mozilla/kumascript/pull/107
* Adding JS-Howto article to learning area sidebar
  https://github.com/mozilla/kumascript/pull/110
* Add 'HTTP range requests' page to HTTP navigation
  https://github.com/mozilla/kumascript/pull/111
* Add VRLayer to WebVR GroupData
  https://github.com/mozilla/kumascript/pull/112
* Bug 1332828: Remove DekiScript-Data.ejs
  https://github.com/mozilla/kumascript/pull/113