Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
refactor(core): update peerDependencies to allow rxjs7 #42991
Conversation
|
Not sure if |
| }, | ||
| "files": [ | ||
| "include-all.ts", | ||
| "node_modules/@types/jasmine/index.d.ts" |
gkalpak
Jul 29, 2021
Member
OOC, shouldn't this be in the types list?
OOC, shouldn't this be in the types list?
crisbeto
Jul 29, 2021
Author
Member
Not sure, I was following the same pattern as the TS tests.
Not sure, I was following the same pattern as the TS tests.
crisbeto
force-pushed the
crisbeto:41897/optional-rxjs-7
branch
from
054e751
to
f7a01bd
|
LGTM, thanks @crisbeto I've just left a comment about |
| @@ -187,7 +187,7 @@ describe('property bindings', () => { | |||
| }) | |||
| class OtherDir { | |||
| @Input() id: number|undefined; | |||
| @Output('click') clickStream = new EventEmitter(); | |||
| @Output('click') clickStream = new EventEmitter<void>(); | |||
AndrewKushnir
Jul 29, 2021
Contributor
Just curious how break-y that would be for apps code as well and whether we should consider doing a migration (schematic) to simplify the upgrade? That also reminds me of #38916...
Just curious how break-y that would be for apps code as well and whether we should consider doing a migration (schematic) to simplify the upgrade? That also reminds me of #38916...
crisbeto
Jul 29, 2021
Author
Member
It'll be pretty break-ey, even for our own code, but as you mentioned, it's not a problem for now because version 7 is opt in. I explored it a bit in #41793 which revealed a few other breaking changes.
It'll be pretty break-ey, even for our own code, but as you mentioned, it's not a problem for now because version 7 is opt in. I explored it a bit in #41793 which revealed a few other breaking changes.
|
This looks good to me. With all the aio tests running on rxjs 7 would should have enough test coverage to know when things break. It's going to be really interesting to see how easy it will be for everyone to get from 6 to 7 and collect pain points that we might need to help or resolve before removing v6 support. Thanks for getting this thought the line. Reviewed-for: global-approvers |
crisbeto
changed the title
We can't update the framework to rxjs7 until version 13, because it contains breaking changes, but we can allow users to opt into it since all of our code should be compatible. These changes expand the allowed version range of rxjs and add an integration test to verify that we don't get compilation errors. Note that we also have a test that runs the AIO examples against rxjs 7 already (#42660). Fixes #41897.
We can't update the framework to rxjs7 until version 13, because it contains breaking changes, but we can allow users to opt into it since all of our code should be compatible. These changes expand the allowed version range of rxjs and add an integration test to verify that we don't get compilation errors. Note that we also have a test that runs the AIO examples against rxjs 7 already (#42660). Fixes #41897. PR Close #42991
We can't update the framework to rxjs7 until version 13, because it contains breaking changes, but we can allow users to opt into it since all of our code should be compatible.
These changes expand the allowed version range of rxjs and add an integration test to verify that we don't get compilation errors. Note that we also have a test that runs the AIO examples against rxjs 7 already (#42660).
Fixes #41897.