Repository navigation
PR #69 seems to be a breaking change in 0.5.8 #74
Description
This would cause a regression in Prettier if we would update @glimmer/syntax or even reinstall @glimmer/syntax@0.41.0 without a workaround in the package resolutions field, see prettier/prettier#6570.
I also noticed cross-references between PR #69, emberjs/ember.js#18530, and glimmerjs/glimmer-vm#960.
I think this kind of a change should not have been in a patch release.
/cc @fisker
Activity
rwjblue commentedon Nov 6, 2019
Ya, in retrospect I agree. I can do a patch release to rerelease 0.5.7 in a 0.5.9 release, then release a "breaking change" release (likely 1.0.0 since I don't see any reason for this lib to be at 0.x) which would be used in current version of
@glimmer/syntax(0.43 IIRC). But I'd still like to get a jump start on figuring out whatever is the actual cause of the failures in prettier/prettier#6570 because we'll want Prettier to update eventually to the current version...brody2consult commentedon Nov 6, 2019
Thanks @rwjblue for your quick attention. To understand what this means for Glimmer, I took a quick look through https://github.com/glimmerjs/glimmer-vm/commits/master/packages/%40glimmer/syntax/package.json.
I noticed that the last 2 minor 0.x releases of
@glimmer/syntaxwere using simple-html-tokenizer@^0.5.8. So I think your idea to re-release 0.5.7 in 0.5.9 patch release could potentially break the recent Glimmer releases, if we do not find a way to mitigate this.brody2consult commentedon Nov 6, 2019
Agreed. Prettier seems to be extremely sensitive to this kind of change, and they had to hold back many updates of dependencies on the 1.x release. I hope they can update all dependencies before Prettier 2.0 release as discussed in prettier/prettier#3503.
fisker commentedon Nov 6, 2019
I suggest release 1.0 for 0.57 2.0 for 0.58 then let glimmer team choose, will not break things
fisker commentedon Nov 15, 2019
@rwjblue sorry to bother, but any solution?