Error while running typescript node using geo-tz in build file

[arun-s-aot]

I am using geo-tz in our typescript node application for getting the geolocation details. When i am running the node server locally, it's working fine but when taken a node server build , i am getting an error like the below while calling geo-tz function like this:

import * as  geoTz from 'geo-tz';
const testGeotz= ()=>{
       try{
           const coords = [110,-20]
            let name = geoTz(coords[1], coords[0])[0];
           }catch (e) {
               console.log(e);
           }
}

Why is it happening like this ?
My node version - 12.16.3
geo-tz version - 6.0.0

I even tried downgrading the geo-tz version and tried to upgrade to latest v6.0.1 .Still same response.
Please tell me whether I have missed out any dependency .
@evansiroky @greenkeeperio-bot

[miguelpfitscher]

This problem is happening here too.

When I use locally, It works. But, when it is build, that happen.

[arun-s-aot]

Any help is appreciated . Not sure how to proceed . We have to rollout the production build within 2 days. Will have to look for alternatives if problem still persists @timotejroiko @greenkeeperio-bot @mtmail

[arun-s-aot]

This problem is happening here too.

When I use locally, It works. But, when it is build, that happen.

Are you using typescript node or normal nodejs ? @miguelpfitscher

[mtmail]

Hardcode data paths you need in lib/find.js locally if you're working against a company deadline.

[timotejroiko]

what do you mean with "locally" and "build"? when its built with tsc? docker? what are the differences between your local nodejs and your server?

[arun-s-aot]

what do you mean with "locally" and "build"? when its built with tsc? docker? what are the differences between your local nodejs and your server?

We are using nx workspace for running the app and building it . Building will transpile typeScript file into JavaScript (under the hood, its what tsc does) . That js file will be used for deploying the node server to aws. We can run the node runtime locally pointing to the corresponding ts file. @timotejroiko

[miguelpfitscher]

This problem is happening here too.
When I use locally, It works. But, when it is build, that happen.

Are you using typescript node or normal nodejs ? @miguelpfitscher

I'm using nodejs on an API.

For now, I'm catching the error and treat it when happen

[miguelpfitscher]

The problem is happening in this lat long.

"lat": -24.244125928804735
"long": -53.8226425697034

[arun-s-aot]

@miguelpfitscher Thanks for the info . I tried with multiple lat and long and its failing in all the cases. Our project needs to deal with multiple vendors in various timezones. So its a crucial part for us. After catching the error, how are you handling it?

[miguelpfitscher]

@miguelpfitscher Thanks for the info . I tried with multiple lat and long and its failing in all the cases. Our project needs to deal with multiple vendors in various timezones. So its a crucial part for us. After catching the error, how are you handling it?

Here is falling just in few lat longs.

For me, this is not so critical, so, we are handling setting a default timezone.

When we truncate the lat long it seems to happen less

[evansiroky]

We are using nx workspace for running the app and building it . Building will transpile typeScript file into JavaScript (under the hood, its what tsc does)...

This is the issue. node-geo-tz lazy-loads the underlying data by default to attempt to not use so much memory. In whatever build process that is being used, all of the data files must still be able to be referenced as these include the precise data about the timezone boundaries. The reason the error occurs for only certain coordinates is that most coordinates will fall into areas that have the timezones pre-calculated and thus don't require loading the underlying geographic data to perform an exact lookup near a boundary with the timezones.

I'm going to leave this issue open as I am not sure what the best way to provide guidance is for this use case. The README already states that this package cannot be used in the browser due to loading a lot of data, but it appears that users are trying to build/transpile/whatever on the server-side too. I am not exactly sure what build systems everybody is using and there might be many, but if there is a way to instruct the build process to include every file within the data folder of this project in a way that those files can be required as needed, that should work.

[godber]

I have two thoughts on this.

• Can someone provide a sample point that triggers this condition so we can test for it?
• Perhaps the library could check for the file on module initialization and error or warn if it's not there. It's weird to encounter a missing file bug 100k records into a process.

[godber]

Nevermind about the sample point ... I now see the example point above.

The problem is happening in this lat long.

"lat": -24.244125928804735
"long": -53.8226425697034

[Cloudmancermedia]

I know I am late to the party here but I may have discovered this bug by accident from a different issue I was having. We were having one issue when trying to use the find function on the frontend web app, and the above issue when attempting to use it in a Lambda. The problem arose from using a lat/long combo with differing decimal point accuracies.

lat: 34.05861
long: -118.3928

Notice 5 and 4 decimal places, respectively. We ended up rounding them to the nearest whole integer and it solved both of the issues. Something weird happens when the function receives a lat and long with differing decimal point lengths. Not sure if it helps, but just something that worked for us.

[VadimCiv]

I know I am late to the party here but I may have discovered this bug by accident from a different issue I was having. We were having one issue when trying to use the find function on the frontend web app, and the above issue when attempting to use it in a Lambda. The problem arose from using a lat/long combo with differing decimal point accuracies.

lat: 34.05861 long: -118.3928

Notice 5 and 4 decimal places, respectively. We ended up rounding them to the nearest whole integer and it solved both of the issues. Something weird happens when the function receives a lat and long with differing decimal point lengths. Not sure if it helps, but just something that worked for us.

Great suggestion, but it doesn't apply to my situation. I'm executing my code on a NextJs API hosted on Vercel

"geo-tz": "^8.0.1"

…Failed to get timezone: Error: ENOENT: no such file or directory, open '/var/task/node_modules/geo-tz/data/timezones-1970.geojson.geo.dat'

export const getTimeZoneByGeo = (lat: number, lng: number) => {
  try {
    const timezones = find(Number(lat.toFixed(4)), Number(lng.toFixed(4)))
    return (timezones.length && timezones[0]) || 'UTC'
  } catch (error) {
    console.error(`Failed to get timezone: ${error}`)
    return 'UTC'
  }
}

Error: ENOENT: no such file or directory, open '/var/task/node_modules/geo-tz/data/timezones-now.geojson.geo.dat'. REQUEST LAT 31.979672370612 LNG 34.752403290084

[PeterBurner]

@evansiroky lazy-loading data is a good approach. However for those using bundlers it would be helpful if the FEATURE_FILE_PATH could be provided via an environment variable. I have seen other libraries also take this approach. Using the static path as fallback would still allow normal usage.

[evansiroky]

Hello all, as of v8.1.0 there is now an option to configure the data directory via an environment variable. This is explained in the "Bundlers" section in the readme.

If this resolves the bundling problems and allows this issue to be closed, please give this comment a thumbs up. If not, please comment on what is missing or, better yet, make a PR to add that improvement. Thanks, all.