[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.

[marcwrobel]

Suggested change

	tags: javascript-runtime herodevs
	tags: javascript-runtime

I am still unsure we should add a herodevs tags. And currently only nvm is tagged with it, so I would prefer if this addition was addressed for all herodevs supported products separately.

[AndreAngelantoni]

Thanks for your input, @marcwrobel

Is there a particular reason HeroDevs shouldn't be one of the tags? We see perhaps a dozen companies in the tag list.

Regarding the longer paragraph, I'll ask Joe where that came from. It does seem to repeat the link a few times.

[marcwrobel]

Is there a particular reason HeroDevs shouldn't be one of the tags? We see perhaps a dozen companies in the tag list.

We have a very strict policy to avoid having too much tags, see https://endoflife.date/contribute. So for now only the product vendor is added in tags.

And for the particular case of herodevs I don't strongly disagree to add one, but I would like to discuss this in another PR so that:

• everybody in the team can give its opinion,
• all products illegible to HeroDevs never-ending support are tagged at once,
• all products having mentioning another third-party support provider also have its tag (to be fair).

[AndreAngelantoni]

@marcwrobel I've kicked off the discussion with a new issue:

Potentially add a herodevs tag for products supported by HeroDevs
#6504