chore: deprecate in favour of @hs-web-team/eslint-config-node

[davidding]

Summary of Changes 📋

[swatinigam]

Hi David, from what I understand, portal-53's Nx version (v19) cannot be upgraded. Since the Cypress version is tied to Nx, it's been stuck on Cypress v13 and can't be updated until Nx is upgraded too. Because of this, portal-53 will need to continue using this package rather than switching to eslint-config-node, which only supports Cypress v15 and above. So, not sure we should deprecate it. If it helps, I could look into adding support for cypress v13 in eslint-config-node in the future.
Please let me know if I am missing anything.

[davidding]

Hi David, from what I understand, portal-53's Nx version (v19) cannot be upgraded. Since the Cypress version is tied to Nx, it's been stuck on Cypress v13 and can't be updated until Nx is upgraded too. Because of this, portal-53 will need to continue using this package rather than switching to eslint-config-node, which only supports Cypress v15 and above. So, not sure we should deprecate it. If it helps, I could look into adding support for cypress v13 in eslint-config-node in the future. Please let me know if I am missing anything.

Hi @swatinigam. My understanding is that the portal-53 repo itself is being deprecated, so we won't be updating any dependencies in that project going forward, anyway - so it can continue to use the final version of this package?

[swatinigam]

Hi David, from what I understand, portal-53's Nx version (v19) cannot be upgraded. Since the Cypress version is tied to Nx, it's been stuck on Cypress v13 and can't be updated until Nx is upgraded too. Because of this, portal-53 will need to continue using this package rather than switching to eslint-config-node, which only supports Cypress v15 and above. So, not sure we should deprecate it. If it helps, I could look into adding support for cypress v13 in eslint-config-node in the future. Please let me know if I am missing anything.

Hi @swatinigam. My understanding is that the portal-53 repo itself is being deprecated, so we won't be updating any dependencies in that project going forward, anyway - so it can continue to use the final version of this package?

Sounds fine to me, thank you!