Skip to content

Commit

Permalink
Update package.json
Browse files Browse the repository at this point in the history
  • Loading branch information
@kyranet
kyranet authored Apr 24, 2018
1 parent 3bdcd47 commit 8c5f4e1
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion package.json
View file
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@
"dist": "./build"
},
"engines": {
"node": ">=4 <=9"
"node": ">=4"
},
"devDependencies": {
"chai": "~4.0.2",
Expand Down

8 comments on commit 8c5f4e1

@lookfirst
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😢

@anodynos
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the problem @lookfirst ?

@lookfirst
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yarn why upath

=> Found "[email protected]"
info Reasons this module exists
   - "react-scripts-ts#webpack#watchpack#chokidar" depends on it
   - Hoisted from "react-scripts-ts#webpack#watchpack#chokidar#upath"

My straight up yarn install fails now because you had that dependency on <= 9 and I'm using node 10 now thanks to brew upgrade. Now, I have to wait for something in that 5 layer dependency tree to update.

In the meantime, yarn install --ignore-engines works (after having to go look up the documentation), but in the meantime, I and whomever else gets to 😢 all because of some commit you did 6 months ago.

Maybe I'm just being a baby. I've probably done much worse dumb shit in my own engineering career. Not your fault. Just reminds me of how brittle software engineering is.

@anodynos
Copy link
Owner

@anodynos anodynos commented on 8c5f4e1 May 2, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep calm & use https://www.npmjs.com/package/upath @1.0.5 which was published last friday.
Just reinstall everything and the relevant libraries should pick up the new version.
Otherwise you can moan onto them authors for fixating versions like that :-)
Yes, Software Engineering is brittle, it's part of the challenge :-) Especially when using cutting edge versions like node@10 BTW, which was released such a short while ago? Why, oh why?
Give it some time, stick to the tried and tested!

@lookfirst
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@anodynos That was a reinstall that caused the failure. Also, I had no choice to use node 10 because brew installed it on an upgrade. I hadn't run one in many months.

I've been in software engineering for 20+ years. I'm not worried about myself, I'm worried about all the kids out there who have to struggle with this stuff. As more experienced engineers, we should aim for less brittle and not have the attitude of it being 'part of the challenge'. The node ecosystem is famous for this type of attitude and ... it isn't flattering.

Thanks to 👍, at least 3 other people have come here and had the same problem, probably a small fraction of the total.

@jiachen247
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it has been "some time"

@romellem
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For anyone who wandered here and is looking for a solution, I discovered a configuration option resolutions that you can set within your package.json

Yarn supports selective version resolutions, which lets you define custom package versions inside your dependencies through the resolutions field in your package.json file. Normally, this would require manual edits in the yarn.lock file.

Why would you want to do this?
You may be depending on a package that is not updated frequently, which depends on another package that got an important upgrade. In this case, if the version range specified by your direct dependency does not cover the new sub-dependency version, you are stuck waiting for the author.

This looks to solve the issue for me. The documentation is a little sparse here, but it looks like you can scope your dependency resolution by adding slashes to your key name.

In my project, [email protected] > [email protected] > [email protected] > [email protected] is the dependency tree, so I scoped this resolution to exactly that.

Here is what my package.json looks like now:

  "dependencies": {
    "webpack": "3.12.0",
    ...
  },
  "resolutions": {
    "webpack/watchpack/chokidar/upath": "1.0.5"
  },

I probably could have done "webpack/**/upath": "1.0.5", as yarn documentation seems to suggest they accept "globstar" support, but scoping this to my exact module worked for me.

# Before adding the `resolutions` key to package.json...
$ yarn install
yarn install v1.16.0
[1/5] 🔍  Validating package.json...
[2/5] 🔍  Resolving packages...
[3/5] 🚚  Fetching packages...
error [email protected]: The engine "node" is incompatible with this module. Expected version ">=4 <=9". Got "10.16.0"
error Found incompatible module.

# After adding the `resolutions` key to package.json...
$ yarn install
yarn install v1.16.0
[1/5] 🔍  Validating package.json...
[2/5] 🔍  Resolving packages...
[3/5] 🚚  Fetching packages...
[4/5] 🔗  Linking dependencies...
[5/5] 🔨  Building fresh packages...
success Saved lockfile.
✨  Done in 355.56s.

@lookfirst
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 355.56s.

😢

Please sign in to comment.