Peer dep ‹three› "^0.135.0" conflicts with latest ‹web-ifc-three› (v0.0.122) own peer dep requirement "^0.149.0"

olange commented 1 year ago

Problem

Since web-ifc-three upgraded its three peer dependency from v0.135 to v0.149 in its latest version 0.0.122, I believe there is currently a mismatch with web-ifc-viewer's own three peer dependency to v0.135.

web-ifc-viewer/viewer/package.json (L61–63):

  …,
  "peerDependencies": {
    "three": "^0.135.0"
  }

web-ifc-three/web-ifc-three/package.json (L65–67):

  …,
  "peerDependencies": {
    "three": "^0.149.0"
  }

Possible solution

I guess web-ifc-viewer's three peer dep should be upgraded to v0.149 as well:

web-ifc-viewer/viewer/package.json (L61–63):

  …,
  "peerDependencies": {
    "three": "^0.149.0"
  }

Steps to reproduce

I ran in this problem, while executing npm install in a project where I am trying to import latest versions of both web-ifc-three (v0.0.122) and web-ifc-viewer (v1.0.213):

  "dependencies": {
    […],
    "web-ifc-three": "^0.0.122",
    "web-ifc-viewer": "^1.0.213"
  },

Error report from NPM:

% npm install
code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR! 
npm ERR! While resolving: […]
npm ERR! Found: three@0.149.0
npm ERR! node_modules/three
npm ERR!   peer three@"^0.149.0" from web-ifc-three@0.0.122
npm ERR!   node_modules/web-ifc-three
npm ERR!     web-ifc-three@"^0.0.122" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! web-ifc-viewer@"^1.0.213" from the root project
npm ERR! 
npm ERR! Conflicting peer dependency: three@0.135.0
npm ERR! node_modules/three
npm ERR!   peer three@"^0.135.0" from web-ifc-viewer@1.0.213
npm ERR!   node_modules/web-ifc-viewer
npm ERR!     web-ifc-viewer@"^1.0.213" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
[…]

olange commented 1 year ago

The reason for which I want web-ifc-three v0.0.122 (instead of v0.0.118) is because web-ifc-three brings in web-ifc v0.0.36, which might solve an issue I'm having with web-ifc v0.0.35 at loading specific IFC files. A long story with drawers.

agviegas commented 1 year ago

Got it. We will update all the versions and dependencies asap!

olange commented 1 year ago

Thanks for your swift feedback. I just discovered IFCjs/web-ifc-three#149, I guess both issues are intermingled.

pablo-mayrgundter commented 1 year ago

Another vote for updating deps.. the three.js peer dep is 2 years old

tymokvo commented 1 year ago

Hello, just wanted to :+1: this when upgrading to web-ifc-viewer@1.0.216.

agviegas commented 1 year ago

Hey! Right now we are focusing all our resources in this repository, which uses the latest versions of all the libraries, is much more powerful (e.g. 200mb IFC in 2 seconds), more maintainable, documented and tested. Once we make an official release (at some point this summer), it is very likely that web-ifc-viewer will be no longer maintained. Many of the APIs are similar, so the transition should be quite easy.

Upgrading web-ifc-viewer to the latest three.js requires time that we can't allocate right now, so we will wait until that release.

RyugaRyuzaki commented 1 year ago

Hi @agviegas . I got errors with this :https://github.com/IFCjs/components/blob/main/examples/fragment-loader-ifc.html

async function convertIfcToFragments() {
        fragments.ifcLoader.settings.wasm = {
            path: "https://unpkg.com/web-ifc@0.0.39/",
            absolute: true,
        };

        fragments.ifcLoader.settings.optionalCategories.length = 0;

        fragments.ifcLoader.settings.webIfc = {
            COORDINATE_TO_ORIGIN: true,
            USE_FAST_BOOLS: true,
        };

        model = await fragments.ifcLoader.load("/02.ifc");
        scene.add(model);

        fragments.culler.needsUpdate = true;
    }

https://unpkg.com/web-ifc@0.0.39/ : this error
https://unpkg.com/web-ifc@0.0.40/ 41 : this error
https://unpkg.com/web-ifc@0.0.42/ : this error Please, can you help?Thank you

agviegas commented 1 year ago

Hey @RyugaRyuzaki can you please open an issue in the components repo? thanks!

tymokvo commented 1 year ago

Thanks for the update @agviegas ! Looking forward to using components! :smile_cat:

pylgrym commented 1 year ago

Just a comment on the status of this: I hear that components apparently will 'solve this elsewhere somehow'.

But status quo means, that no version newer than 1.0.213 can be used in practice? (web-ifc-viewer@1.0.213) That is, if I type npm install web-ifc-viewer@1.0.213 --save it still works. But if I try to use any newer version (1.0.214 to 1.0.218), npm reports broken circular dependencies, which it is not clear to me library users can solve? (am I mistaken?)

For people considering professional/commercial use of IFC.js, it appears unsettling, that three sibling libraries can grow out of whack like this.. Maybe it is because I don't fully grasp how it could happen. I am not trying to be snarky here, I am just assuming that in the context where those changes happened/were developed, there would have been a reasonable configuration of those dependendies A, B and C, and if us 'clients' were to replicate the same set of dependency versions, it should compile/resolve on our machines in the same way..? I am currently evaluating IFC.js for commercial use, and I find this situation concerning, possibly because I don't understand the situation fully.

agviegas commented 1 year ago

Hey @pylgrym,

We will officially deprecate web-ifc-three and web-ifc-viewer in less than a month. We Will keep both libraries up, but they won't be maintained in the future. Instead, everyone should use the components library.

IFC.js is a young project, and what we are trying to solve here is not a known problem. We don't think this situation will happen again in the future, but this is the only way we can make all the improvements and discoveried of the last month a reality.

I think it's important to note that today neither you nor the rest of the users of the library are clients, as the code is free and open and has been maintained by a bunch of great devs in their free time.

That being said, the project is now scaling and becoming a company to become sustainable, and it is likely that the speed of development, stability and support will improve a lot. We have a big launch scheduled for September 20 (including a brand new documentation with tutorials). After that date, there might be "clients", but the code will remain free and open.

Companies like Bosch, Enel and Ferrovial are already using components. If you think our code fits your company, you are free to use it. If not, you can propose improvements, help to improve, choose another alternative or create your own library.

Cheers!

pylgrym commented 1 year ago

Thank you, great to hear. You are moving in a space, where catenda, revit forge and xbim also move. "heavy" support for IFC takes a great amount of resources, and adoption of your library by major players/commercial players, I believe, is part of what can bring in such necessary resources. I hope it will continue to grow, as it looks very promising on first impressions, relatively to my experience setting up those other libraries.

On Thu, 31 Aug 2023 at 14:48, Antonio González Viegas < @.***> wrote:

Hey @pylgrym https://github.com/pylgrym,

We Will officially deprecate web-ifc-three and web-ifc-viewer in less than a month. We Will keep both libraries up, but they won't be maintained in the future. Instead, everyone should use the components library.

IFC.js is a young project, and what we are trying to solve here is not a known problem. We don't think this situation will happen again in the future, but this is the only way we can make all the improvements and discoveried of the last month a reality.

I think it's important to not that today neither you nor the rest of the users of the library are clients, as the code is free and open and has been maintained by a bunch of great devs in their free time.

That being said, the project is now scaling and becoming a company to becomes sustainable, and it is likely that the speed of development, stability and support will improve a lot. We have a big launch scheduled for September 20. After that date, there might be "clients", but the code will remain free and open.

Companies like Bosch, Enel and Ferrovial are already using components. If you think our code fits your company, you are free to use it. If not, you can propose improvements, help to improve it or choose another alternative.

Cheers!

— Reply to this email directly, view it on GitHub https://github.com/IFCjs/web-ifc-viewer/issues/188#issuecomment-1700976664, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVBASN4BMWB6ZJKSA4423LXYCBY7ANCNFSM6AAAAAAU6OUDF4 . You are receiving this because you were mentioned.Message ID: @.***>

jgaardsted commented 1 year ago

Since the above exchange, I have been trying to run and evaluate your mentioned replacement 'openbim-components'. I do run into some difficulties trying to do so. (I realise you say it will release in what is still the future - september 20.)

I start from the WIP documentation at https://github.com/IFCjs/components, which only really shows how to do the three.js part (which is already possible without IFC/web-ifc).

I then look at the samples in the same folder (https://github.com/IFCjs/components/tree/main/examples) However, they no longer build with rollup, but instead straight JS modules, partially deployed at https://unpkg.com. However, openbim-components itself does NOT come from unpck.com, but is instead somehow directly included in the examples-repo, as the file 'openbim-components.js'.

But I cannot figure out where this openbim-components.js comes from, or what version it is; it appears to date from april 3rd 2023.

If I install https://www.npmjs.com/package/openbim-components, I find no such openbim-components.js, but instead a lot of smaller files. So I am unsure how to go from an npm package to 'openbim-components.js' used in the examples. Whenever I try to build webifc stuff with rollup, I run into a lot of import errors regarding the .js suffix, e.g.

[!] Error: Could not load c:\Apache24\htdocs\other\ifcee3\node_modules\three\examples\jsm\renderers\CSS2DRenderer (imported by node_modules/openbim-components/core/SimpleRenderer/index.js): ENOENT: no such file or directory, open 'c:\Apache24\htdocs\other\ifcee3\node_modules\three\examples\jsm\renderers\CSS2DRenderer'

I could fix these by adding '.js' to the import, like this: .. import { CSS2DRenderer } from "three/examples/jsm/renderers/CSS2DRenderer.js"; .. but clearly I am missing something with either webifc or rollup, given that your examples don't build (I saw the same issues when I looked at the earlier web-ifc documentation examples. That is, when I try to load them out of the box, I get those ".js suffix missing from imports").

..Anyway.. The reason I am messing with these things, is because if I try to run the original openbim-components samples, the examples involving IFC don't appear to work - instead they die with this:

XHRGET https://unpkg.com/web-ifc@0.0.39/web-ifc.wasm  [HTTP/2 200 OK 54ms]
XHRGET http://localhost/other/ifcjs_comp/resources/01.ifc [HTTP/1.1 200 OK 0ms]

INFO:  Parsing Model using IFC2X3 Schema [openbim-components.js:84677:15](http://localhost/other/ifcjs_comp/resources/openbim-components.js)
Uncaught (in promise) TypeError: lengthUnits.Name is null
    setUp http://localhost/other/ifcjs_comp/resources/openbim-components.js:86382
    generateFragmentData http://localhost/other/ifcjs_comp/resources/openbim-components.js:86629
    loadAllGeometry http://localhost/other/ifcjs_comp/resources/openbim-components.js:86910
    load http://localhost/other/ifcjs_comp/resources/openbim-components.js:86901
    funWithFragments http://localhost/other/ifcjs_comp/jg_ifc.html:72
    <anonymous> http://localhost/other/ifcjs_comp/jg_ifc.html:76
[openbim-components.js:86382:13](http://localhost/other/ifcjs_comp/resources/openbim-components.js)

So, I was trying to get updated versions of the code involved, to see if something has changed, but I can't figure out how to pull updated versions, with the currently available resources.

I also tried upgrading to newer versions of unpkg.com/web-ifc@0.0.39 (e.g. version 40,41,42,43), but as soon as I try that, it complains method OpenModel() is no longer part of the API?

To recap/TL;DR: I was originally curious about some minor inconveniences in IFC.js, and thus arrived in this issue #188. Here it is explained, that web-ifc.js will be superceded by openbim-components "soon/any minute now". So I've turned my attention to this replacement, to evaluate it. But as it is still awaiting "public" release (I assume), I've had difficulties getting it to run, and to figure out how to configure its dependencies.

In particular: (1) - I cannot figure out how to use 'openbim-components' as imported javascript-modules, given that the available examples instead use a raw js blob of uknown provenance. (2) - I cannot figure out how to instead bundle 'openbim-components' with rollup.js (your earlier used demo bundler), because it triggers a host of .js suffix errors of the type

[!] Error: Could not load c:\Apache24\htdocs\other\ifcee3\node_modules\three\examples\jsm\renderers\CSS2DRenderer (imported by node_modules/openbim-components/core/SimpleRenderer/index.js): ENOENT: no such file or directory, open 'c:\Apache24\htdocs\other\ifcee3\node_modules\three\examples\jsm\renderers\CSS2DRenderer'

(3) - I cannot get the IFC loader to work in your provided examples, because it dies with

Uncaught (in promise) TypeError: lengthUnits.Name is null
in setUp http://localhost/other/ifcjs_comp/resources/openbim-components.js:86382

I'm looking forward to next developments, but currently I can only figure out how to get old-style web-ifc.js to work :-/.

Cheers, Jakob.

UPDATE: Hmm, I could circumvent one of the errors by changing this line in the openbim-components.js file "of uknown origin":

if (lengthUnits.Name?.value === "FOOT") { //if (lengthUnits.Name.value === "FOOT") {

jgaardsted commented 1 year ago

FYI. After I modified the '(lengthUnits.Name.value === "FOOT")' like, I have been able to run evaluations on openbim-components. I get some rather weird results.

I have been timing loadings of a vide variety of IFC model sizes, ranging from a few MB to about a gigabyte. In general, I observe a slow-down of about a factor of 5x, relative to the old web-ifc?

That is a rather extreme slowdown. I wonder, if the currently provided openbim-components demo is configured to run in some kind of debugging mode slowing it down?

I run the two viewers in parallel on the same machine, alternating between loading a model in the old and new version. In some cases, the slowdown rises to a factor of 13x, but 5x is the 'average' behaviour.

I wonder if it is because the newer version is more strict/more validating with regards to 'bad IFC', and that the older version similarly is more lax/devil-may-care?

The models come from a variety of tools, so it is not just a matter of 'one vendor making particularly broken IFC' (Tekla, I'm looking at you..)

I run on a relatively beefy workstation laptop that is about 12 months old, with gobs of ram.

I will see if I can find some relevant discussion of the components stuff in the Discord group.

agviegas commented 1 year ago

Hi @jgaardsted ,

It is a bit hard for us to track things down if we use issues as places for open conversations / chat around. If you have specific questions about components, please open new issues that repository (one per question/topic). The more concise, the easier for us to help you. Thanks in advance!

You can also check out the new documentation.

For more open conversations, you can visit our new community, which will substitute discord. This is a moment of change for the project, so you can expect some chaos while we migrate to the new community, but hopefully all this will make the project much better.

jgaardsted commented 1 year ago

UPDATE: Hello. Just now, I believe these issues have been resolved, and were instead artifacts of the earlier alphas.

After your 20-sep release, I today redid the tests with your new components-stuff, and the issues described above seem gone:

in most cases, I see identical loading-times to the old version.
only in a single instance did I see a longer loading time (2x), which I suspect is tied to more strict/correct handling in your new software.
further, the new version handles larger models, and more robustly. A 750M IFC file that took 30+ minutes with old version, now loads in under 3 minutes and works!

Congratulations on your great work!

ThatOpen / web-ifc-viewer