PR #69 seems to be a breaking change in 0.5.8

[brody4hire]

ref: PR #61 / issue #21:

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

[rwjblue]

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...

[brody4hire]

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/syntax were 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.

[brody4hire]

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

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]

I suggest release 1.0 for 0.57 2.0 for 0.58 then let glimmer team choose, will not break things

[fisker]

@rwjblue sorry to bother, but any solution?