ember-cli-typescript: [RFC] What constitutes a breaking change?
Because of #246 / https://github.com/DefinitelyTyped/DefinitelyTyped/pull/28282 we’ve hit a point where we have to think about how SemVer, library version and the Ember/TS version support policy interact.
TL;DR - a feature was added to TS 3.1 nightly builds which caused @types/ember to break. TypeScript regards their change as non-breaking, and thus appropriate for a minor release.
However – to get things working in @types/ember, we’ve had to use TypeScript 2.8 features. In a sense, we’ve definitely broken things for someone who’s using TypeScript 2.4. There are a variety of packages that depend on @types/ember that will need to be bumped up before we can merge in the fix
- @types/ember-data
- @types/ember-feature-flags
- @types/ember-mocha
- @types/ember-modal-dialog
- @types/ember-qunit
- @types/ember-qunit/v2
- @types/ember-resolver
- @types/ember-test-helpers
- @types/ember__test-helpers
I believe some options to discuss are
(1) Bump everything up, and encourage everyone to start using TypeScript 2.8 (this is what the PR currently does)
(2) Take the current types, put them in a /v2 folder, and alter all the dependencies such that they point to /v2. After nothing depends on the v2 types, merge in the fix as the first commit of a v3 release series
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 15 (15 by maintainers)
It feels like we have consensus here. I’ll close this in a couple of days and open PR(s) to put the plan into action
@dfreeman part of closing this out will involve writing a vanilla node module to expose utilities to help make decisions about explicitly upgrading a dependency (or not). I want us to write a crazy number of unit tests around a pure function to ensure the blueprint does what we want it to.