Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix ci #379

Merged
merged 22 commits into from Feb 24, 2022
Merged

fix ci #379

merged 22 commits into from Feb 24, 2022

Conversation

NullVoxPopuli
Copy link
Contributor

@NullVoxPopuli NullVoxPopuli commented Feb 15, 2022

Most of the diff is from the yarn.lock file

The commits show a progression of why or what changed if you like reviewing that way. I'm also happy to squash if that's what folks would like.

Summary

  • changes supported ember version to 3.12, 3.16 to 3.28, 3.24
    • (canary, beta, release, default) still present
  • updates @glimmer/component's dependencies to be compatible with the newer ember versions
    • mainly: ember-auto-import@v2 is required for ember 4+
  • applied addon blueprint over @glimmer/component (for the specified ember-source in that package.json) -- most of the diff is from these sorts of changes
  • upgrades @glimmer/vm (and related dependencies)
  • ember-component-manager changed from using Ember global apis to @ember/destroyable
    • I've been under the impression that this is the correct way to handle destruction
  • ember-qunit and related changes are part of the v5 upgrade
  • html-inlen-precomile premoved in favor of ember-cli-htmlbars
  • minimum typescript version changed from 3.1 to 4.0
    https://github.com/glimmerjs/glimmer.js/pull/379/files#diff-f17a36b7758421e673e4dae6c85e48d2a576da5bf873a4582ea563bcd2e5d742

Points of Interest

What this PR Unblocks

@locks
Copy link
Contributor

locks commented Feb 15, 2022

Would this close #230 ?

@NullVoxPopuli
Copy link
Contributor Author

partially -- I think deciding on a policy should still happen. I'm in favor of mirroring ember's support here

@@ -51,7 +51,7 @@ jobs:

strategy:
matrix:
ember-version: [default, release, beta, canary, lts-3.12, lts-3.16]
ember-version: [default, release, beta, canary, lts-3.28, lts-3.24]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was dropping support tied to the requirements for the @cached decorator, or is it just because/part of the blueprint update? (i.e. are we able to keep the older Ember versions if we wanted to?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can give it a go -- I was mainly going with the ember support policy, cause I don't know what the glimmer one is

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i guess it's fine 🙃
(assuming we trust the tests)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I wasn't implying that we should do it one way or the other, just wanted to know if it was deliberate/required or out of convince (what could be fine). Although, now that you proved that it works (at least according to the tests), if it doesn't end up hurting anything, I personally would be inclined to keep the support to aid adoption (though we should also include 3.20 in the matrix in that case).

However, I do think it is important to double check and make sure we in fact could support the @cached decorator on all of these versions, at least before we release 2.0 final.

@@ -0,0 +1,5 @@
{
"application-template-wrapper": false,
"jquery-integration": false,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't have the async observer stuff, intentional?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It turns out that I had an extra optional-features file.

This file, the traditional location, is the only place where the test runner looks for these options, afaict. I've moved the more complete optional-features.json to this location so that it's proper octane (including async observers)

@@ -1 +1 @@
// Minimum TypeScript Version: 3.1
// Minimum TypeScript Version: 4.0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Normally I think there are some consequences with this, but given that we apparently need to release a major version bump anyway, this is probably fine. Though @chriskrycho should probably confirm just in case. (I am not sure how much of the @glimmer/* types ended up being consumed directly, as opposed to being replaced/superseded by the Glint wrappers anyway.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is indeed breaking! And at this point the majority of the ecosystem is not using Glint, in past because addons cannot do so. (That’s one of the big motivations for moving the Signature RFC forward.) If this is intending to target a 2.0 release, the breaking change is fine. Otherwise we should leave it at its previous value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already have to do a breaking change anyway without doing an enormous (imo) amount of work to support from ember 3.12 to current (macros, no more partials, etc)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems fine, then, with two caveats:

  1. I believe there are a number of other changes already queued up for a v2, so we need to evaluate those as part of this work.
  2. We need to make sure that end users can actually successfully have both v1 and v2 active in an app's codebase, since it will take some time to migrate the ecosystem.

Two additional considerations:

  • We can support the Glint Signature changes without a breaking change, but it would be much easier to not. We need to decide on what to do with that.
  • There are other changes we want to make to align the Glimmer.js API with the version of the Glimmer component API available in Ember.js, specifically around lifecycle hooks. I am not sure if those have yet landed, but we need to follow up and evaluate those before we actually publish the v2.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what specific things do we need to do to move forward?
(I'm not clear on what next steps are)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the most part, I don't think should affect this PR, considering we already released 17 (!) betas for 2.0.0. But those are probably checklist items for the 2.0.0 final.

@chancancode
Copy link
Contributor

  • ember-component-manager changed from using Ember global apis to @ember/destroyable
    • I've been under the impression that this is the correct way to handle destruction

Hmm, actually this might be a good enough reason to drop < 3.24, or else we probably need to do some Embroider macro things to make it work. But in any case, I am confused why the tests are passing?

@chancancode
Copy link
Contributor

Thanks for putting this together and providing the context for the changes, they are super helpful!

@NullVoxPopuli
Copy link
Contributor Author

enough reason to drop < 3.24

I've re-dropped 3.12 and 3.16. I think the destroyable stuff was added in 3.22, and I don't trust the test suite with ember-source < 3.22

@chancancode
Copy link
Contributor

Seems like we will need a checklist for the 2.0 release outside of this PR (and one of the items should be landing the @cached decorator), @chriskrycho do you mind making one (or make a milestone, whatever)? Seems like you have more context on what is needed.

Separately, I am pretty concerned that the test were passing with 3.12/3.16 in the matrix since there is no destroyable APIs. @NullVoxPopuli can you investigate what's up, or at least open an issue? Are we just missing some test coverage around destruction, or were the tests running at all?

In any case both of those things are not directly related to this PR, I think we are good to proceed. Also wouldn't mind if @rwjblue could give this a look when he is back to see if I missed anything around the upgrades. Thanks again @NullVoxPopuli for taking care of this!

@chancancode chancancode merged commit ee9fbf0 into glimmerjs:master Feb 24, 2022
@NullVoxPopuli
Copy link
Contributor Author

Thanks! <3

Issue here (for now, I gotta pivot to some embroider work for the near near term)
#382

@chriskrycho
Copy link
Contributor

Thanks for suggesting that, @chancancode – I just opened #383 to that end!

@NullVoxPopuli NullVoxPopuli deleted the fix-ci-34f8a7e7ps branch February 25, 2022 00:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants