Skip to content

Conversation

@bary822
Copy link

@bary822 bary822 commented Jan 5, 2018

Previous syntax to specify this package's version unintentionally installs previous version in terms of semantic versioning.
This is because definition of latest version in NPM is the latest version in chronological order.
For example, if a package releases version 1.1.0 after releasing 2.0.0, package-name: '*' installs 1.1.0,
which @types/node often does.
This commit makes sure we will keep depending on 8.x.x version of @types/node.

hfukui@linuxmint ~/Projects/parse5 $ npm install
...
> publish-please@2.3.1 postinstall /home/hfukui/Projects/parse5/node_modules/publish-please
> node lib/init.js


> parse5@3.0.3 prepublish /home/hfukui/Projects/parse5
> publish-please guard

parse5@3.0.3 /home/hfukui/Projects/parse5
├── @types/node@8.5.5 
├─┬ del@2.2.2 
│ ├─┬ globby@5.0.0 
...

Previous syntax to specify this package's version unintentionally installs previous version in terms of semantic versioning.
This is because definition of `latest version` in NPM is the latest version in **chronological** order.
For example, if a package releases version 1.1.0 after releasing 2.0.0, package-name: '*' installs 1.1.0,
which @types/node often does.
This commit makes sure we will keep depending on 8.x.x version of @types/node.
@inikulin inikulin mentioned this pull request Jan 11, 2018
17 tasks
@inikulin
Copy link
Owner

@bary822 Thank you for the contribution. Seems like it's a part of the bigger TypeScript workflow-related problem, so I'll close this one in favour of #235

@inikulin inikulin closed this Jan 11, 2018
@bary822 bary822 deleted the lock-types-node-version branch January 12, 2018 02:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants