-
Notifications
You must be signed in to change notification settings - Fork 64
Make dependencies' sort locale independent #276
Conversation
At issue here isn't the differences between 6 and 7, its the idempotency of the action. The results shouldn't differ based on end user locale. This PR is going to be unable to merge after #273 is landed, because this function was inlined into So while I think this is a good change, we'll have to wait for the other PR to land so this one can be re-applied there. We will also want to have a test that goes inside the |
Other places where we use
|
Ok, new plan. Instead of dropping |
Node will use the current environment's locale sorting for String.localeCompare. Thankfully, String.localeCompare can take a second argument to specify the locale. Up until Node 13, any valid argument provided to the function _may_ be respected if Node was compiled with Intl support, or would always be treated as `'en'` otherwise. The solution is to always set the locale to `'en'`. An alternative solution would be to compare strings based on byte order, but this does not provide ideal ergonomis. To verify this, the locale is set in the test environment to `'sk'`, which has a significantly different alphabet, including sorting words starting with `'ch'` _after_ words starting with `'d'`. Re: npm/cli#2829 Fix: #276
Node will use the current environment's locale sorting for String.localeCompare. Thankfully, String.localeCompare can take a second argument to specify the locale. Up until Node 13, any valid argument provided to the function _may_ be respected if Node was compiled with Intl support, or would always be treated as `'en'` otherwise. The solution is to always set the locale to `'en'`. An alternative solution would be to compare strings based on byte order, but this does not provide ideal ergonomis. To verify this, the locale is set in the test environment to `'sk'`, which has a significantly different alphabet, including sorting words starting with `'ch'` _after_ words starting with `'d'`. Re: npm/cli#2829 Fix: #276
Node will use the current environment's locale sorting for String.localeCompare. Thankfully, String.localeCompare can take a second argument to specify the locale. Up until Node 13, any valid argument provided to the function _may_ be respected if Node was compiled with Intl support, or would always be treated as `'en'` otherwise. The solution is to always set the locale to `'en'`. An alternative solution would be to compare strings based on byte order, but this does not provide ideal ergonomis. To verify this, the locale is set in the test environment to `'sk'`, which has a significantly different alphabet, including sorting words starting with `'ch'` _after_ words starting with `'d'`. Re: npm/cli#2829 Fix: #276
Going with the approach in #280. Thanks for bringing this to our attention! |
Node will use the current environment's locale sorting for String.localeCompare. Thankfully, String.localeCompare can take a second argument to specify the locale. Up until Node 13, any valid argument provided to the function _may_ be respected if Node was compiled with Intl support, or would always be treated as `'en'` otherwise. The solution is to always set the locale to `'en'`. An alternative solution would be to compare strings based on byte order, but this does not provide ideal ergonomis. To verify this, the locale is set in the test environment to `'sk'`, which has a significantly different alphabet, including sorting words starting with `'ch'` _after_ words starting with `'d'`. Re: npm/cli#2829 Fix: #276
Node will use the current environment's locale sorting for String.localeCompare. Thankfully, String.localeCompare can take a second argument to specify the locale. Up until Node 13, any valid argument provided to the function _may_ be respected if Node was compiled with Intl support, or would always be treated as `'en'` otherwise. The solution is to always set the locale to `'en'`. An alternative solution would be to compare strings based on byte order, but this does not provide ideal ergonomis. To verify this, the locale is set in the test environment to `'sk'`, which has a significantly different alphabet, including sorting words starting with `'ch'` _after_ words starting with `'d'`. Re: npm/cli#2829 Fix: #276
Node will use the current environment's locale sorting for String.localeCompare. Thankfully, String.localeCompare can take a second argument to specify the locale. Up until Node 13, any valid argument provided to the function _may_ be respected if Node was compiled with Intl support, or would always be treated as `'en'` otherwise. The solution is to always set the locale to `'en'`. An alternative solution would be to compare strings based on byte order, but this does not provide ideal ergonomis. To verify this, the locale is set in the test environment to `'sk'`, which has a significantly different alphabet, including sorting words starting with `'ch'` _after_ words starting with `'d'`. Re: npm/cli#2829 Fix: #276
this will fix npm's sorting of dependencies in
package.json
npm/cli#2829now dependencies in
package.json
are sorted locale dependent, which makes npm unusable on non-english systemssame problem was fixed in 2017 https://github.com/npm/npm/pull/17844/files but now sorting package.json and package-lock.json are again locale independend in npm 7
for me this is a big issue, because some of us in our company is working with english OS, some in slovak and both package.json and package-lock files are changing with every npm install
if you are on *nix system, you can test
LC_ALL=sk npm i
andLC_ALL=en-US npm i
(as described in issue above). but on windows there is no way to change sort language.npm 6 from 2017 fix use native
.sort()
, which useC.UTF-8
sort, now npm 7 use localeCompare, which changed sorting even on English systems:-
is now after_
.so fixing this by forcing sorting to
en-US
locale makes npm 6 and npm 7 dependencies sorted different