Turfjs / turf

A modular geospatial engine written in JavaScript and TypeScript

Home Page:https://turfjs.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Module Import/Types Issues

charlieforward9 opened this issue · comments

Turf Versions: ^6.5.0

I followed the basic instructions of installing the individual Turf modules, but kept getting this error:

Could not find a declaration file for module '@turf/XXX'. '/XXX/node_modules/@turf/XXX/dist/es/index.js' implicitly has an 'any' type. There are types at '/XXX/node_modules/@turf/XXX/dist/js/index.d.ts', but this result could not be resolved when respecting package.json "exports". The '@turf/XXX' library may need to update its package.json or typings.

I found this SO discussion that mentioned a minor syntactical shift in the package.json of the module. I performed this change and the linting error went away.

"exports": {
    "./package.json": "./package.json",
    ".": {
+     "types": "./dist/js/index.d.ts",
      "import": "./dist/es/index.js",
      "require": "./dist/js/index.js"
    }
  },
- "types": "/dist/js/index.d.ts",

This seems to be a necessary change for the library, which I would be happy to contribute to if it is not already being addressed.

Thanks for logging this issue @charlieforward9. We've made some changes to address this and a few other type issues. I took at look at the StackOverflow thread you included, and I think the changes will help, although they're not exactly the same.

Would you mind taking a look and seeing if you can spot any potential problems or improvements? An example of the changes are in

"type": "commonjs",
"main": "dist/cjs/index.cjs",
"module": "dist/esm/index.mjs",
"types": "dist/cjs/index.d.ts",
"exports": {
"./package.json": "./package.json",
".": {
"import": {
"types": "./dist/esm/index.d.mts",
"default": "./dist/esm/index.mjs"
},
"require": {
"types": "./dist/cjs/index.d.ts",
"default": "./dist/cjs/index.cjs"
}
}
},

If that looks like it might help, those changes will go out with 7.0.0-alpha.3, hopefully in a week or so.

@smallsaucepan Seems like you linked this branch that you'd like me to test which, when merged should close this issue?

same issue here, looking forward to update

Seems like you linked this branch that you'd like me to test which, when merged should close this issue?

@charlieforward9 i think he was just asking if you could scan that code change and provide feedback on if you think it's the type of change you would expect to fix the issue. When the alpha.3 comes can test to be sure

@twelch @smallsaucepan The code looks valid, I would like to be able to test it in my repo and use this branch until the alpha.3 release is available. Can I replace "^6.5.0" with "smallsaucepan/turf#pnpm-migration" or do I need to do something else as I am importing the turf modules like this:

    "@turf/area": "^6.5.0",
    "@turf/bbox": "^6.5.0",
    "@turf/boolean-point-in-polygon": "^6.5.0",
    "@turf/helpers": "^6.5.0",

I have a continuous deployment pipeline that is breaking because I have manually changed the dependencies in node_modules/ to work as specified in the Issue Description, so I need a solution as soon as possible. Thank you.

@charlieforward9 it doesn't quite work that way. A build isn't in the repo itself for you to just grab from any branch, it's published as a separate step to npm. That pnpm branch is just one of many going into the next alpha. I think you'll just have to be patient.

@twelch I was afraid this would be the case... it was mentioned earlier that alpha.3 is supposed to be coming out this week, but it seems that is not the case anymore. Is there a new projected release date?

I hear you. I think @smallsaucepan was hopeful. This is a library maintained by volunteers so I would suggest there is no release date, even when one is hinted. There's work happening on the very machinery that produces and publishes the builds so once that's stable I think it will get done.

@twelch Thanks for the explanation. I have worked a bit with open source projects and have had many discussions with their volunteers so I know its not as streamlined and predictable as a business operation. As I am working on a team that depends very much on this engine, I will likely become a volunteer myself down the road. Is there a location where this work/discussions are discussed or tracked?

Outside of issues, Github discussions is the best place to ask and interact - https://github.com/Turfjs/turf/discussions.

@charlieforward9 if you already were able to patch it in a way that resolves the issue, you can try this patching technique mentioned here - #2498 (comment)

Hi @charlieforward9. Another approach you could try would be to build Turf from source, deploy to a local node repo, and install from there. It's more infrastructure work up front, though less impact on your client code.

It's not as bad as it sounds. Half an hour ball park. Take a look at the wiki for a how to:
https://github.com/Turfjs/turf/wiki/Contributing#deploy-to-a-local-node-registry

News flash @charlieforward9! Since I responded above an even easier option has opened up. The VERY talented @mfedderly has configured the repo to generate a new alpha with every merged PR. For example, the still hot out of the oven @turf/area 7.0.0-alpha.110 should have the most up to date Turf code, able to be installed directly from npmjs.com. No need to set up local npm repos.

Please give it a try and see how you go!

Hey @smallsaucepan , I realize I never you back to you on this. I can confirm that this works with 7.0.0-alpha.113.

Assuming this is how v7 will be by default, I will assume that this is fixed moving forward and close the issue. Thank you very much for the detailed response.