[node.js] Add new commercial support column.

[AndreAngelantoni]

The changes in this PR are:

• added a new column controlled by page.commercialSupportColumn that can be turned on a product-by-product basis
• modified the product.html to optionally use the new column
• modified the products/nodejs.md file to use the new column
• added a new paragraph with links for users to learn about commercial support.

[welcome]

Thank you for opening this pull request 👍. If you are not familiar with the project, please check out our Contributing Guidelines and our Guiding Principles. Also take a look at our Hacking Guide if you intend to work on site internals.

[captn3m0]

We already have a eoes column, which is being used for any kind of extended support, including commercial. Lets use that instead of defining a new column.

See the https://endoflife.date/angular page for example.

[AndreAngelantoni]

@captn3m0 Happy to do that but it doesn't look to me that the column will work for this.

The logic uses the date (in part) to determine the status/color:

    {% if page.eoesColumn %}
    {%- assign colorClass = 'bg-green-000' %}
    {%- if r.days_toward_eoes < page.eoesWarnThreshold %}{% assign colorClass = 'bg-yellow-200' %}{% endif %}
    {%- if r.days_toward_eoes < 0 or r.eoes == true %}{% assign colorClass = 'bg-red-000' %}{% endif %}
    {%- if r.eoes == null %}{% assign colorClass = 'bg-grey-lt-100' %}{% endif %}
    <td class="{{ colorClass }}">
      {% if r.eoes_from %}
        {% if r.is_eoes %}Ended{% else %}Ends{% endif %}
        {{ r.eoes_from | timeago }} <div>({{ r.eoes_from | date_to_string }})</div>
      {% else %}
        {% if r.is_eoes == null %}Unavailable{% else %}{% if r.is_eoes %}No{% else %}Yes{% endif %}{% endif %}
      {% endif %}
    </td>
    {% endif %}

That may have worked for the Angular support but for this product support is not dependent on the date in any way:

| Version  | Commercial Support? |
| -------- | ------------------- |
| 23       | No                  |
| 22       | No                  |
| 21       | No                  |
| 20       | No                  |
| 19       | No                  |
| 18       | Yes                 |
| 17       | No                  |
| 16       | Yes                 |
| 15       | No                  |
| 14       | Yes                 |
| 13       | No                  |
| 12       | Yes                 |
| 11       | No                  |
| 10       | No                  |
| 9        | No                  |
| 8        | No                  |
| 7        | No                  |
| 6        | No                  |
| 5        | No                  |
| 4        | No                  |
| 3        | No                  |
| 2        | No                  |
| 1        | No                  |

What if I add some commentary with the code that explains why this extra column is required?

[AndreAngelantoni]

I suppose I could alter the code to handle a "hard yes" and a "hard no."

Not attached to either way, just let me know what you'd like me to do. :-)

[AndreAngelantoni]

@captn3m0 I'm reviewing the code in product.html and I'm seeing duplication:

      {% if page.eoasColumn %}<th>{{ page.eoasColumnLabel }}</th>{% assign colCount = colCount | plus:1 %}{% endif %}
      {% if page.eolColumn %}<th>{{ page.eolColumnLabel }}</th>{% assign colCount = colCount | plus:1 %}{% endif %}
      {% if page.eoesColumn %}<th>{{ page.eoesColumnLabel }}</th>{% assign colCount = colCount | plus:1 %}{% endif %}
  

And two of these but they are slightly different:

  {% if page.eoasColumn %}
   {%- assign colorClass = 'bg-green-000' %}
   {%- if r.days_toward_eoas < page.eoasWarnThreshold %}{% assign colorClass = 'bg-yellow-200' %}{% endif %}
   {%- if r.days_toward_eoas < 0 %}{% assign colorClass = 'bg-red-000' %}{% endif %}
   <td class="{{ colorClass }}">
   {% if r.eoas_from %}
     {% if r.is_eoas %}Ended{% else %}Ends{% endif %}
     {{ r.eoas_from | timeago }} <div>({{ r.eoas_from | date_to_string }})</div>
   {% else %}
     {% if r.is_eoas %}No{% else %}Yes{% endif %}
   {% endif %}
   </td>
   {% endif %}

...

   {% if page.eoesColumn %}
   {%- assign colorClass = 'bg-green-000' %}
   {%- if r.days_toward_eoes < page.eoesWarnThreshold %}{% assign colorClass = 'bg-yellow-200' %}{% endif %}
   {%- if r.days_toward_eoes < 0 or r.eoes == true %}{% assign colorClass = 'bg-red-000' %}{% endif %}
   {%- if r.eoes == null %}{% assign colorClass = 'bg-grey-lt-100' %}{% endif %}
   <td class="{{ colorClass }}">
     {% if r.eoes_from %}
       {% if r.is_eoes %}Ended{% else %}Ends{% endif %}
       {{ r.eoes_from | timeago }} <div>({{ r.eoes_from | date_to_string }})</div>
     {% else %}
       {% if r.is_eoes == null %}Unavailable{% else %}{% if r.is_eoes %}No{% else %}Yes{% endif %}{% endif %}
     {% endif %}
   </td>
   {% endif %}

[captn3m0]

Can you clarify what's the duplication? It's three separate columns eoas, eoes, and eol.

Further, you can leave eoes unset (null) which shows "Unavailable", which is intentional. Also explained in our contribute page:

# End Of Extended/commercial Support date (optional if eoesColumn is true, else SHOULD NOT be set).
# This can be either a date (must be valid and not quoted), a boolean value (when
# the date is not known or has not been decided yet), or null.
# - When a date is used, this is where the extended support period stops.
# - When a boolean is used, it must be set to true if the extended support period is over,
#   and false otherwise.
# - When null is used, it means that there is no extended/commercial support for the given
#   release cycle.

You can see an example at https://endoflife.date/eclipse-jetty.

We are generally wary of adding new columns - this means new API/schema changes which need a lot more thought. Since there's only a single extended support available (which happens to be commercial), lets use eoes.

[AndreAngelantoni]

@captn3m0 for the duplication comment, I retract that: I read too quickly and thought the variable names were the same.

Thank you for your other comments, that clarified things for me and I've submitted changes that produce the following result:

[AndreAngelantoni]

@captn3m0 checking in...is this better? Cheers.