Releases: immutable-js/immutable-js
v5.0.2
v5.0.1
What's Changed
Fixes
- Fix circular dependency issue with ESM build by @iambumblehead in #2035
Internal
- Upgrade TSTyche by @mrazauskas in #2034
Full Changelog: v5.0.0...v5.0.1
v5.0.0
Breaking changes
To sum up, the big change in 5.0 is a Typescript change related to Map
that is typed closer to the JS object. This is a huge change for TS users, but do not impact the runtime behavior. (see Improve TypeScript definition for Map
for more details)
Other breaking changes are:
[BREAKING] Remove deprecated methods:
Released in 5.0.0-rc.1
Map.of('k', 'v')
: useMap([ [ 'k', 'v' ] ])
orMap({ k: 'v' })
Collection.isIterable
: useisIterable
directlyCollection.isKeyed
: useisKeyed
directlyCollection.isIndexed
: useisIndexed
directlyCollection.isAssociative
: useisAssociative
directlyCollection.isOrdered
: useisOrdered
directly
[BREAKING] OrdererMap
and OrderedSet
hashCode implementation has been fixed
Released in 5.0.0-rc.1
Fix issue implementation of hashCode
for OrdererMap
and OrderedSet
where equal objects might not return the same hashCode
.
Changed in #2005
[BREAKING] Range function needs at least two defined parameters
Released in 5.0.0-beta.5
Range with undefined
would end in an infinite loop. Now, you need to define at least the start and end values.
If you need an infinite range, you can use Range(0, Infinity)
.
[Minor BC break] Remove default export
Released in 5.0.0-beta.1
Immutable does not export a default object containing all it's API anymore.
As a drawback, you can not immport Immutable
directly:
- import Immutable from 'immutable';
+ import { List, Map } from 'immutable';
- const l = Immutable.List([Immutable.Map({ a: 'A' })]);
+ const l = List([Map({ a: 'A' })]);
If you want the non-recommanded, but shorter migration path, you can do this:
- import Immutable from 'immutable';
+ import * as Immutable from 'immutable';
const l = Immutable.List([Immutable.Map({ a: 'A' })]);
[TypeScript Break] Improve TypeScript definition for Map
Released in 5.0.0-beta.1
If you do use TypeScript, then this change does not impact you : no runtime change here.
But if you use Map with TypeScript, this is a HUGE change !
Imagine the following code
const m = Map({ length: 3, 1: 'one' });
This was previously typed as Map<string, string | number>
and return type of m.get('length')
or m.get('inexistant')
was typed as string | number | undefined
.
This made Map
really unusable with TypeScript.
Now the Map is typed like this:
MapOf<{
length: number;
1: string;
}>
and the return type of m.get('length')
is typed as number
.
The return of m.get('inexistant')
throw the TypeScript error:
Argument of type '"inexistant"' is not assignable to parameter of type '1 | "length"
If you want to keep the old definition
This is a minor BC for TS users, so if you want to keep the old definition, you can declare you Map like this:
const m = Map<string, string | number>({ length: 3, 1: 'one' });
If you need to type the Map with a larger definition
You might want to declare a wider definition, you can type your Map like this:
type MyMapType = {
length: number;
1: string | null;
optionalProperty?: string;
};
const m = Map<MyMapType>({ length: 3, 1: 'one' });
Keep in mind that the MapOf
will try to be consistant with the simple TypeScript object, so you can not do this:
Map({ a: 'a' }).set('b', 'b');
Map({ a: 'a' }).delete('a');
Like a simple object, it will only work if the type is forced:
Map<{ a: string; b?: string }>({ a: 'a' }).set('b', 'b'); // b is forced in type and optional
Map<{ a?: string }>({ a: 'a' }).delete('a'); // you can only delete an optional key
Are all Map
methods implemented ?
For now, only get
, getIn
, set
, update
, delete
, remove
, toJS
, toJSON
methods are implemented. All other methods will fallback to the basic Map
definition. Other method definition will be added later, but as some might be really complex, we prefer the progressive enhancement on the most used functions.
Fixes
- Fix type inference for first() and last() #2001 by @butchler
- Fix issue with empty list that is a singleton #2004 by @jdeniau
- Map and Set sort and sortBy return type #2013 by @jdeniau
Internal
- [Internal] Migrating TS type tests from dtslint to TSTyche #1988 and #1991 by @mrazauskas.
Special thanks to @arnfaldur that migrated every type tests to tsd just before that. - [internal] Upgrade to rollup 3.x #1965 by @jdeniau
- [internal] upgrade tooling (TS, eslint) and documentation packages: #1971, #1972, #1973, #1974, #1975, #1976, #1977, #1978, #1979, #1980, #1981
Full Changelog: v4.3.3...v5.0.0
v5.0.0-rc.2
What's Changed
- Map and Set sort and sortBy return type by @jdeniau in #2013
- Try to fix issue with empty list that is a singleton by @jdeniau in #2004
Full Changelog: v5.0.0-beta.5...v5.0.0-rc.2
v5.0.0-rc.1
What's Changed
- Fix type inference for first() and last() by @butchler in #2001
- Fix issue with OrderedMap, OrderedSet and hashCode by @jdeniau in #2005
Full Changelog: v5.0.0-beta.5...v5.0.0-rc.1
v4.3.7
v4.3.6
What's Changed
Internals
- change youtube image by @jdeniau in #1973
- Upgrade eslint and ignore no-constructor-return rule for actual constructors by @jdeniau in #1974
- upgrate documentation website to next 14 by @jdeniau in #1975
- start migrating to nextjs app router by @jdeniau in #1976
- upgrade next sitemap by @jdeniau in #1978
New Contributors
Full Changelog: v4.3.5...v4.3.6
v5.0.0-beta.5
What's Changed
Merge fixes from v4.3.5
v4.3.5
5.0.0-beta.4
Revert tree-shaking possibility as it does break. Moreover, as nearly every collection type can be converted to another collection (Map().toList()
for example), so nearly no code was removed.
I think that if we want to implement this, we might need to rethink this functionality.