three-stdlib icon indicating copy to clipboard operation
three-stdlib copied to clipboard

Published 20 hours ago • verified publisher icon pmndrs

Building produces broken typescript

Open mrshmllow opened this issue 2 years ago • 2 comments

unknown-6.png

Using almost anything this package causes crazy type/resolution errors. Building from master it produces type definitions that import random stuff that doesn't exist. For instance from one of those above errors, src/nodes/utils/TimerNode.d.ts imports from "../inputs/FloatNode" which doesn't exist at all. Using the latest from npm has the same issue

sorry for how low quality this issue i am away from my computer right now

mrshmllow avatar Apr 15 '22 11:04 mrshmllow

Hello, I think I created this issue related to the same kind of problem : https://github.com/pmndrs/three-stdlib/issues/148 I hope it will be fixed soon... Have a good day !

BenLune avatar Apr 20 '22 12:04 BenLune

same. thank you

mrshmllow avatar Apr 20 '22 12:04 mrshmllow

@drcmda @joshuaellis This seems quite problematic since it fails type-checking when skipLibCheck is set to false. I would like to help resolve this issue, but I'm not sure of the best path forward. It seems like the current solution of copying the types from @types/three will not be maintainable long-term as they keep diverging. What would you think of removing the attempt to copy types from @types/three and instead trying to enable allowJs and fixing any errors with that?

Methuselah96 avatar Aug 30 '22 11:08 Methuselah96

Or if the goal is to keep them mostly aligned with the three examples, is there a way to know which examples have intentionally diverged and which ones haven't? Just browsing through the files, it seems like a lot of them have not diverged, but don't have the latest changes from the three examples in various ways (for example, ShadowMapViewier is now a class using const and let in the three.js examples, but is still a function with a prototype using var in this repo.

Methuselah96 avatar Aug 30 '22 12:08 Methuselah96

@drcmda After looking into it some more, it appears that many of the examples have not been modified since they were copied from three, so it seems to make sense to continue using the types from @types/three where needed. Here is a PR to resolve this issue while still sticking with the current strategy: https://github.com/pmndrs/three-stdlib/pull/176.

Methuselah96 avatar Aug 30 '22 17:08 Methuselah96

:tada: This issue has been resolved in version 2.15.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

github-actions[bot] avatar Sep 03 '22 14:09 github-actions[bot]