You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it is time to consider moving to a new level of browser support for ArcGIS REST JS. When we launched 4.0 we switched the TypeScript compiler to ES2017 so we could use async/await.
Moving to ES2020 would get us the optional chaining operator ?. plus a bunch of other native features that would be nice to have.
Additionally I would like to upgrade to Typescript 5 to take advantage of the new moduleResolution=bundler which would allow us to drop the .js from imports.
My main question is should these be done as breaking changes? Technically they are since they could cause REST JS to stop working in older browsers but at the same time is support for things like Chrome 55 (October 2016) really necessary?
Describe the proposed solution
Updates compiler to ES2020, upgrade to TypeScript 5.
Alternatives considered
We could hold this until v5 which I would like to do after Hub.js upgrades to v4.
Additional Information
None
The text was updated successfully, but these errors were encountered:
karma-typescript only supports up to Typescript 4. So if we want to upgrade to compile with TypeScript 5 we have to replace karma as our runner for browser tests with something else.
No problem lets use [jasmine-browser-runner]
jasmine-browser-runner doesn't support TypeScript out-of-the-box so you have do compile all the tests AND all the source files to JS so they can run in the browser directly.
jasmine-browser-runner also doesn't support code coverage so we would loose our code coverage tooling. No problem we can replace that with istanbul/nyc directly.
istanbul/nyc doesn't seem to play nicely with TypeScript + ESM + Jasmine out-of-the-box.
`fetch-mock is also behind 3 major versions as well
At this point we cannot upgrade TypeScript without either rewriting most of our test stack OR abandoning the 100% code coverage that is at the heart of REST JS's reliability. This is pretty depressing since.his current system hasn't even lasted 4 years.
There are however lots of alternatives with various sets of tradeoffs:
We could use web-test-runner but it does not run in Node JS at all so that would limit us to browser tests and we still have to configure Mocha + Chai + Typescript + ESM to run in Node if we still wanted browser and Node tests.
We could switch to something like Vitest or Jest which only run in Node with additional options to run in the browser like Browser Mode for Vitest or Jest Preview. This might also mean abandoning fetch-mock or at least updating to| newer version. If we went this route we could still run a separate smaller griup of tests for browser specific oAuth workplows.
Describe the problem
I think it is time to consider moving to a new level of browser support for ArcGIS REST JS. When we launched 4.0 we switched the TypeScript compiler to
ES2017
so we could useasync
/await
.Currently ES2017 has 97.47% global support and ES2020 has 95.5% global support.
Moving to ES2020 would get us the optional chaining operator
?.
plus a bunch of other native features that would be nice to have.Additionally I would like to upgrade to Typescript 5 to take advantage of the new
moduleResolution=bundler
which would allow us to drop the.js
from imports.My main question is should these be done as breaking changes? Technically they are since they could cause REST JS to stop working in older browsers but at the same time is support for things like Chrome 55 (October 2016) really necessary?
Describe the proposed solution
Updates compiler to
ES2020
, upgrade to TypeScript 5.Alternatives considered
We could hold this until v5 which I would like to do after Hub.js upgrades to v4.
Additional Information
None
The text was updated successfully, but these errors were encountered: