| ▲ | melbourne_mat 7 days ago |
| First thing I would have done is upgrade the version of Gatsby to latest. Did the author try that? If upgrading is difficult because of 4 years of breaking changes, blame Gatsby for not being backwards compatible. Also blame your original choice of going with a hokey framework. Speaking of hokey framework: 167 dependencies and 3000 versions of Gatsby in npm. |
|
| ▲ | Eric_WVGG 6 days ago | parent | next [-] |
| The first thing I would have done is check the version of Node. That's a quick fix, upgrading a framework is a guaranteed min hour of poking around before the system is even running. I dunno why `engines` isn't in every `package.json` file, would certainly have saved me hours of nonsense. |
|
| ▲ | baq 7 days ago | parent | prev [-] |
| blaming anything or anyone gets you exactly zero seconds closer to getting the job done. |
| |
| ▲ | tomgp 7 days ago | parent [-] | | You could perhaps reframe "blame" as identifying the source of the problem and iunderstand why it can be a useful excercise (aslo none of us here are trying to solve the problem really, just wasting time on the internet). In this case Node and it's atendant ecosystem are certainly a part of the problem but I would agree that Gatsby is a bigger part of the issue as they don't seem to have any interest in taming the Node dependecy management beast. I've had to dig into Gatsby projects mere months old and it really was like opening a can of worms. | | |
| ▲ | Eric_WVGG 6 days ago | parent [-] | | > In this case Node and it's atendant ecosystem are certainly a part of the problem but I would agree that Gatsby is a bigger part of the issue I disagree completely. Regardless of what you think of Gatsby, Node versioning is a simple problem that affects nearly every javascript project. It should always be the first thing you check. I made this dumb obvious mistake again just last week, looking for a little time to audit all my `package.json` files for `engines`. |
|
|
