After paket update, SAFE Stack run fails unless Fable.Elmish is pinned to 3.1.0

[geysernrd]

Here is the error output (obviously the [MY_DIRECTORY] stuff is a manual overwrite of my directory structure in the original error message):

client: ERROR in ./src/Client/output/fable_modules/Fable.Elmish.React.4.0.0/react.fs.js 3:0-43
client: Module not found: Error: Can't resolve 'react-dom/client' in '[MY_DIRECTORY]\src\Client\output\fable_modules\Fable.Elmish.React.4.0.0'
client: resolve 'react-dom/client' in 'C:\Development\RoundTable\Excalibur\src\Client\output\fable_modules\Fable.Elmish.React.4.0.0'
client:   Parsed request is a module
client:     resolve as module
client:       [MY_DIRECTORY]\src\Client\output\fable_modules\Fable.Elmish.React.4.0.0\node_modules doesn't exist or is not a directory
client:       [MY_DIRECTORY]\src\Client\output\fable_modules\node_modules doesn't exist or is not a directory
client:       [MY_DIRECTORY]\src\Client\output\node_modules doesn't exist or is not a directory
client:       [MY_DIRECTORY]\src\Client\node_modules doesn't exist or is not a directory
client:       [MY_DIRECTORY]\src\node_modules doesn't exist or is not a directory
client:       looking for modules in [MY_DIRECTORY]\node_modules
client:         existing directory [MY_DIRECTORY]\node_modules\react-dom
client:           using description file: [MY_DIRECTORY]\node_modules\react-dom\package.json (relative path: .)
client:             using description file: [MY_DIRECTORY]\node_modules\react-dom\package.json (relative path: ./client)
client:               no extension
client:                 [MY_DIRECTORY]\node_modules\react-dom\client doesn't exist
client:               .js
client:                 [MY_DIRECTORY]\node_modules\react-dom\client.js doesn't exist
client:               .json
client:                 [MY_DIRECTORY]\node_modules\react-dom\client.json doesn't exist
client:               .wasm
client:                 [MY_DIRECTORY]r\node_modules\react-dom\client.wasm doesn't exist
client:               as directory
client:                 [MY_DIRECTORY]r\node_modules\react-dom\client doesn't exist
client:       [HIGHER_DIRECTORY]\node_modules doesn't exist or is not a directory
client:       [EVEN_HIGHER_DIRECTORY]\node_modules doesn't exist or is not a directory
client:       C:\node_modules doesn't exist or is not a directory

I've confirmed that this occurs with a new, clean SAFE app with the latest SAFE template. Framework is net6.0 and I'm using VS Code. If Fable.Elmish is pinned to version 3.1.0, the SAFE app builds and runs.

[olivercoad]

I still think we should do #487 to prevent issues like this.

On Sat., 11 Mar. 2023, 06:03 geysernrd, @.***> wrote:

Here is the error output (obviously the [MY_DIRECTORY] stuff is a manual overwrite of my directory structure in the original error message):

client: ERROR in ./src/Client/output/fable_modules/Fable.Elmish.React.4.0.0/react.fs.js 3:0-43 client: Module not found: Error: Can't resolve 'react-dom/client' in '[MY_DIRECTORY]\src\Client\output\fable_modules\Fable.Elmish.React.4.0.0' client: resolve 'react-dom/client' in 'C:\Development\RoundTable\Excalibur\src\Client\output\fable_modules\Fable.Elmish.React.4.0.0' client: Parsed request is a module client: resolve as module client: [MY_DIRECTORY]\src\Client\output\fable_modules\Fable.Elmish.React.4.0.0\node_modules doesn't exist or is not a directory client: [MY_DIRECTORY]\src\Client\output\fable_modules\node_modules doesn't exist or is not a directory client: [MY_DIRECTORY]\src\Client\output\node_modules doesn't exist or is not a directory client: [MY_DIRECTORY]\src\Client\node_modules doesn't exist or is not a directory client: [MY_DIRECTORY]\src\node_modules doesn't exist or is not a directory client: looking for modules in [MY_DIRECTORY]\node_modules client: existing directory [MY_DIRECTORY]\node_modules\react-dom client: using description file: [MY_DIRECTORY]\node_modules\react-dom\package.json (relative path: .) client: using description file: [MY_DIRECTORY]\node_modules\react-dom\package.json (relative path: ./client) client: no extension client: [MY_DIRECTORY]\node_modules\react-dom\client doesn't exist client: .js client: [MY_DIRECTORY]\node_modules\react-dom\client.js doesn't exist client: .json client: [MY_DIRECTORY]\node_modules\react-dom\client.json doesn't exist client: .wasm client: [MY_DIRECTORY]r\node_modules\react-dom\client.wasm doesn't exist client: as directory client: [MY_DIRECTORY]r\node_modules\react-dom\client doesn't exist client: [HIGHER_DIRECTORY]\node_modules doesn't exist or is not a directory client: [EVEN_HIGHER_DIRECTORY]\node_modules doesn't exist or is not a directory client: C:\node_modules doesn't exist or is not a directory

I've confirmed that this occurs with a new, clean SAFE app with the latest SAFE template. Framework is net6.0 and I'm using VS Code. If Fable.Elmish is pinned to version 3.1.0, the SAFE app builds and runs.

— Reply to this email directly, view it on GitHub https://github.com/SAFE-Stack/SAFE-template/issues/553, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF5P62VGVTFTUEUHI7QGDJ3W3N3I7ANCNFSM6AAAAAAVW27MYI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[geysernrd]

@olivercoad, I could not agree more. I'm not a hobbyist nor a contributor, but I am who the community is (or at least should be) trying to attract. I'm a real-life professional user of this technology, an investment officer for a small investment advisory, and I picked this tech stack because of the (accurate!) promise that I could build a powerful website for our financial planning clients very rapidly. But I didn't realize the extent to which I was signing up for these kinds of issues. For instance, our site was stable since the last update in November, but then I was asked for a new feature. It took me 15 minutes to build the feature and then two full days of experimentation to figure out how to fix (or band-aid or sidestep) the four (four! in four months!) bugs that were introduced by third-party updates, three of them in this stack and one in SQLProvider. This is not the pit of success...

[halcwb]

@geysernrd Exactly the same issue here. Spent a lot of time figuring out which of the dependencies brakes the solution and how to fix this. In the end, you'll have to go through this pain, but this is something you want to pick and choose, not having to deal with as a side effect.

So, the challenge is to come up with a setup that on the one end stabilizes the application such that you can add or change features along the road without third party dependencies breaking the application.

And, on the other end, have a recipe to enable to move the application along the updates of the tech stack.

That said, without the SAFE-template, this is even a bigger problem. The SAFE-stack just isn't the silver bullet (yet).

[mattgallagher92]

@olivercoad I also agree that we should do #487. I'll reopen it to so that we can revisit that conversation.

As you say @halcwb, we need to find the right balance between stability and ease of updating existing dependencies. In my opinion, we don't provide enough stability at the moment.

@geysernrd can you clarify why you want to run paket update? Updating versions of dependencies entails exactly this kind of risk (hopefully mitigated if we implement #487). I tend to only upgrade individual packages on an as-needed basis.

[geysernrd]

Hi @mattgallagher92,

That's a fair question, and it may simply be that my expectations don't really match the philosophical approach of the community, and that I should modify my process to look more like yours. In this particular case, the proximate reason for paket update was to pull in updates to my own libraries, which I push/pull to/from Azure Artifacts. So in this instance I clearly could have just updated my own stuff, and I would have been happier if I had.

In general, though, I prefer to keep stuff relatively up-to-date--within the confines of a major stack version--for a couple reasons. First, it's nice to be reasonably confident that new (or new to me) features I research and plan to use will be available. Also, when the inevitable breaking change requires modifications to my code, I prefer to catch it ASAP, so that I don't have a pile of those issues further complicating the already significant inevitable complexity when I do upgrade major versions.

But of course, for this approach to work, I need to be able to trust that my dependencies will properly handle their dependencies, and that I won't keep running into these errors under the hood where the "it just works" magic happens. :-) This doesn't seem crazy to me. The .NET stack had already basically solved "DLL hell" 20 years ago, when I first started building websites with ASP.NET. OTOH, that was mostly maintained by a team inside Microsoft, and I can understand why it could be much harder for a distributed community to pull it off. Still, my thought is that eliminating this problem would be a big milestone for achieving end user acceptance of the stack, and I certainly agree that #487 seems like a great step.

[mattgallagher92]

@geysernrd I can see the value in your approach. As you say though, it requires trust that transitive dependencies are handled well. In my experience, we're not there yet. The maintainers of the SAFE Template don't really have much control over that: we're mostly pulling together separate libraries maintained by other people and recommending them as useful in combination.

We could of course raise issues and/or PRs in the libraries we're combining, in order to tighten their dependency declarations. It's something we'll pay closer attention to in future—in fact I'll raise an issue for reviewing that now—but it's going to take some time to get there.

In my opinion, #487 and the new issue should cover the problems raised in this one, so I think this issue should be closed. I'll give you a chance to respond first though so that this doesn't drop off our radar.

[geysernrd]

Thanks @mattgallagher92, that sounds like a great plan. Unless there is a better solution to the specific issue that started the thread, might it also be worth pinning Fable.Elmish to 3.1.0 in the paket dependencies for now?

[geysernrd]

Sorry, delayed afterthought: If the idea is that #487 should be resolved before specifying any versions in the paket dependencies, feel free to close this issue now. I only thought it might be worth hitting that specific item, since it is a current issue. (I think? TBH, I haven't checked again in the interim. The fact that it could be resolved by now is obviously a counter-argument! I wonder if it could make sense to have a minor stack upgrade protocol that involves nothing more than upgrading dependency versions to known stable version combos?)

[mattgallagher92]

Hi @geysernrd sorry for the delay, I've been away. I think it would have been worth pinning Fable.Elmish, but there's now a PR (#559) to address #487, which should also prevent this issue.

Not quite sure what you mean by "minor stack upgrade protocol". Do you mean a periodic review of the pinned versions to try to keep them current? I'm sure we'll do that every so often, but let us know if you meant something else.

[geysernrd]

Hi @mattgallagher92, that PR looks great, I'm going to incorporate it into my dependencies.

Yup, a periodic review is all I meant. I was thinking when a working atomic set of upgrades was confirmed, it could be announced as "Version 4.1" (or 4.0.1 or whatever), where the only thing to upgrade to get related new features is the dependency file. But now that I write that out loud, it feels like overkill, and obviously I can just train myself to check Github for upgrades to that file. :-)

Thanks for your help and for putting up with my random musings!