Running without babel

[rowanwins]

Hey there,

Just a heads up that I'm experiencing some issues running 1.0.0-beta.3 in node in a non-babel project.

I'm doing something basic like

const GeoTIFF = require('geotiff');

GeoTIFF.fromFile('./LC80990692014143LGN00_B2.TIF')
  .then(tiff => {
    console.log(tiff)
  })
  .catch(err => {
    console.log(err)
  })

And it throws

Error: Cannot find module 'babel-runtime/helpers/possibleConstructorReturn'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:548:15)
    at Function.Module._load (internal/modules/cjs/loader.js:475:25)
    at Module.require (internal/modules/cjs/loader.js:598:17)
   ....

Have also tried requiring geotiff.bundle.js but that left me with

TypeError: (0 , _fs.open) is not a function
    at eval (webpack-internal:///143:822:18)
    at new Promise (<anonymous>)

I'm running on node v9

Cheers
Rowan

[constantinius]

Hi @rowanwins

Thank you for reporting this issue.

It seems like this is a tough spot, and I'm not sure if there is a suitable workaround right now other than to use babel.

I was not aware of that but I learned in #50 that the import/export syntax is not yet supported in node, so using the source files in src/ will probably not work.
On the other hand, the bundling is configured for browser use only, so typical node modules (like fs) are deliberately left empty, which results in the error you have seen.

The options I see are:

• make your own bundle, please look at the webpack.config.js and delete the node section, and then rebuild
• Install the babel-runtime

I would love to help out, but unfortunately, I'm completely bogged down in other projects, so I cannot work on a solution at the moment.

[rowanwins]

Yeah no worries @constantinius

Probably the best thing I can think of would be reconfiguring the build process, perhaps creating one node-focused webpack config, and one browser-focused webpack config. I can potentially take a look into that at some stage so you may see a pull request although like you my time is limited :)

[DanielJDufour]

Hi @constantinius and @rowanwins . You may have already thought of it, but I'd like to offer this hacky code as a potential workaround :-)

const fs = require("fs");
const GeoTIFF = require("geotiff/dist/geotiff.bundle.min.js");

const buffer = fs.readFileSync("/tmp/test.tif");

// convert Buffer to ArrayBuffer
const arrayBuffer = buffer.buffer.slice(buffer.byteOffset, buffer.byteOffset + buffer.byteLength);

GeoTIFF.fromArrayBuffer(arrayBuffer).then(tiff => {
  console.log(tiff);
});

[constantinius]

That is actually a pretty good idea, thanks @DanielJDufour. This particular source might work for smaller files, but on the other hand, you could just copy the relevant source, instantiate it and use the GeoTIFF.fromSource function to create it.

[PacoDu]

Hi,
I personally don't like to have to import babel in my NodeJS projects ... 🤢 It would be nice if we could create a clean NodeJS build !

I'm not a regular user of babel, but I still don't understand why we need to import babel once the package is built ... I probably misunderstood the purpose of Babel here but, isn't it about polyfill and should not appear as a dependency when using the built version ?

Also, note that since NodeJS 13.2.0+ import / export are properly handled by NodeJS and --experimental-modules is no longer required, adding "type": "module" to package.json should be enough to run .js files as ES modules.

[PacoDu]

If we have to keep babel for any raison, maybe it would be better to define it as a peerDependency in the package.json.

[constantinius]

I believe that a lot has changed since I introduced babel back in the days. Both browser, node and tooling landscapes have significantly improved. I think a very scrutinizing look should be cast upon all the (dev-) dependencies, as I believe many are outdated.

Regarding babel in particular: I'm a bit surprised to hear that it is actually still part of the runtime libs. I think there was a PR/discussion once that introduced it, but I thought it was averted. Seems like I was wrong.

@PacoDu you seem to be familiar with node packages, so I would be glad for you insight how you package such a library without dropping support for versions of node still in use. Do you have experience with that?

[PacoDu]

@constantinius I have some knowledge about node package but I always try to keep every thing up to date without thinking about backward compatibility. But I can take some time to take a look at geotiff.js package.json and build configuration, which versions of NodeJS do you want to support ? (NodeJS LTS is currently v12)

[constantinius]

That is very much appreciated, thank you very much!

I guess we should take v12 as our lower end.