GP library is starting to hit issues with still using Common JS. Notably modern flatgeobuf node client module is a pure ESM module and using it in CJS environment have struggled to make it work, so we are pinned to an older version of flatgeobuf. But the flatgeobuf format seems to have had a breaking change, GDAL 3.5 and up produces flatgeobuf files that flatgeobuf node module v3.17.4 cannot read, produces a "Not a flatgeobuf file" error. The solution is downgrading to GDAL 3.2.2 or below.
We might be able to solve getting latest flatgeobuf node module to load and kick the can down the road, but the longer we stick with CJS, the greater the pain will be. The question is are all the gp dependencies esm-ready? Is Jest? Webpack? Storybook?
The crux things to solve for gp are:
webpack still works for building and running/loading gp functions (node) and clients (browser)
Renaming files to .js and getting jest to still work with its separate transpiler
Local cog works with ts-node for precalc, but loading from seasketch geoprocessing does not
Flatgeobuf works
Ensuring the gp projects can use gp lib still, everything works.
Changes required
In CommonJS in node you can import a directory, and if a index.js exists in that directory, it will open that. ESM requires exact paths
Update package.json to include ”type”: “module” and correct exports field
Refactor all require statements to use import
Refactor all relative-path import statements to include .js file extension
Update Babel Configuration in React to support “import assertions”
__dirname doesn't exist, you only have import.meta
Requirements
[ ] add eslint
[ ] add webpack 5
[ ] upgrade to latest flatgeobuf
[ ] esModuleInterop, should it be true or become false?
twelch
commented
3 months ago
GP library is starting to hit issues with still using Common JS. Notably modern flatgeobuf node client module is a pure ESM module and using it in CJS environment have struggled to make it work, so we are pinned to an older version of flatgeobuf. But the flatgeobuf format seems to have had a breaking change, GDAL 3.5 and up produces flatgeobuf files that flatgeobuf node module v3.17.4 cannot read, produces a "Not a flatgeobuf file" error. The solution is downgrading to GDAL 3.2.2 or below.
We might be able to solve getting latest flatgeobuf node module to load and kick the can down the road, but the longer we stick with CJS, the greater the pain will be. The question is are all the gp dependencies esm-ready? Is Jest? Webpack? Storybook?
The crux things to solve for gp are:
Changes required
package.jsonto include”type”: “module”and correctexportsfieldrequirestatements to useimport.jsfile extensionRequirements
Approach
Geoprocessing library:
GP project:
References