Closed tcompa closed 2 weeks ago
How much simpler are we talking here? If it's a big help, we drop it and work towards using e.g. Node 20 at FMI once we want to deploy web viewers there as well. If it's only a few minor imports, let's not drop it just yet
If it's only a few minor imports, let's not drop it just yet
It's most likely a small set of code changes, but the additional requirement is that we need to set up automated testing so that we can test multiple versions of node - since doing it manually during development is not efficient. And those have to be end-to-end tests, since they are the only ones that would have caught an error like the one related to those imports above.
I am obviously in favor of setting up tests, but I'd look for a tradeoff between the need to support node16 at some point and the cost of developing end-to-end tests at this early stage. A reasonable solution seems to be that we currently keep developing on node18 or node20 (while maintaining node16 compatibility at a best-effort level), and postpone a bit the work on automated testing (which will have to appear, at some point, independently on node versions).
A reasonable solution seems to be that we currently keep developing on node18 or node20 (while maintaining node16 compatibility at a best-effort level), and postpone a bit the work on automated testing (which will have to appear, at some point, independently on node versions).
Sounds very reasonable to me! Let's not actively break Node 16, but no need to test for it currently. When this becomes more mature, let's see if we still need to support Node 16 & test things then
I noticed a few (minor) node-16-related diffs like https://github.com/fractal-analytics-platform/fractal-data/pull/12/files#diff-841254fe75488c1bd4cd7f68f00b4be0e48dcfbc4a16b45847b68295e0e3b27bR7-R8
Question (cc @jluethi): do we need to support node 16 in this project? I guess that deprecating it could make development a bit simpler.