Add backwards compatibility - support for prototypes made in Version 6 of the kit

[joelanman]

Read the guidance

username/password: test/test

Download the zip

This approach isolates old prototypes in a separate folder (app/v6) served by a separate app (created in server.js).

This avoids any clash in Nunjucks templates between old and new, as the v6 app only has access to old v6 views, and the normal app only has access to new views.

Keeping all user code in app is a good thing, as anything outside (as in the old /lib/backwards-compatibility approach) would be lost if users follow our update instructions to delete everything outside of app.

If a route or page exists in both apps, the new app wins over the v6 app.

It only requires one manual change from users - to find and replace /public/ to /public/v6/ in their code.

This PR:

• Adds old modules (Elements, Frontend Toolkit, GOV.UK Template)
• Adds Gulp task to copy assets from app/v6/assets to /public/v6
• Adds Gulp task to process sass in /app/v6/assets/sass by including Elements
• Adds a v6App to server.js with its own Nunjucks environment, to avoid clash between new and old views.
• Changes the matchRoutes function to use next, so a request for one app can fall through to the next app.
• Adds error handling middleware, that we now need due to the use of next
• Adds documentation on how to use backwards compatibility

[joelanman]

BUG: checked function is missing from the v6 Nunjucks environment

[kr8n3r]

tested with https://github.com/stephenjoe1/pay-staff-tool-2 and works great

[dashouse]

Totally non-blocking comment – Only concern on my end is that some users may have the expectation that backwards compatibility will some how convert or map your old code to new things.

Is there any benefit in being explicit about that the old parts of your prototype will still be using GOV.UK Elements / Frontend Toolkit / Template or just see if it comes up?

[joelanman]

@dashouse good point, the documentation does mention 'Updating your code' quite a lot, which implies the code isn't being converted. It's not come up with 2 or 3 people I've tested with so far, but totally open to suggestions if you have anything in mind?

[dashouse]

@joelanman If it's not come up with those users then that's a good sign. I was just thinking if you had the opportunity to ask people submitting old prototypes "what do you expect from compatibility mode?" it would be interesting to know...but it seems like that might have been covered 👍

[hannalaakso]

Tested with https://github.com/alphagov/temporary-event-notice-prototype and works well, I can view pages from the old and new prototype which is pretty cool 👍 Left a couple of small comments.

[hannalaakso]

Would it make sense for this step to come after "Copy everything from the new Prototype Kit folder into your prototype folder."? It would make it clearer that the steps before these are all for the user's old prototype.

[joelanman]

excellent idea

[hannalaakso]

It might be good to add a comment about what "v6" is here, or maybe just link to the changelog entry.

[hannalaakso]

As these arguments are now set in three different places in the file, I wonder if we might want to have them as a shared variable to reduce duplication. But if the intention is to have the v6 code here for the short term only then the current approach is okay for me 🙂

[joelanman]

good idea, but the express property is different in each one so I think this is tricky

[joelanman]

Can we do something to support old unbranded?

Done

another thing I found - if anyone has been using the unbranded template, they’ll need to copy that from their original lib into the top level v6 folder (edited)
(I was just pulling directly from lib)