Use node 16 for development instead of node 14

[NullVoxPopuli]

Pre-req for converting to a v2 addon.

According to @chriskrycho, we're preparing for a major anyway: #1249 (comment)

Requirement stems from: wessberg/rollup-plugin-ts#202

[bertdeblock]

To me, it seems a bit strange to drop support for a specific Node version, just because rollup-plugin-ts accidentally included a breaking change in a minor release. Also, isn't rollup-plugin-ts only needed pre-publish?

EDIT: Also, I forgot, the node engines range will probably be removed anyways when converting to v2?

[NullVoxPopuli]

yup, true true -- so I guess.. motivation is wrong, but the dropping node 14 for development is still correct

[kategengler]

Ember-CLI must still support Node 14 per our policy https://github.com/ember-cli/ember-cli/blob/master/docs/node-support.md. If this addon drops Node 14 we will not be able to update the version used in the blueprint until ember-cli drops Node 14.

[NullVoxPopuli]

@kategengler when this addon is converted to a v2 addon, node doesn't matter at all.

the node version is irrelevant, as this will become browser-only code.

This PR only affects the required development version of node -- so only affects folks who want to add features/fixes to @ember/test-helpers

[kategengler]

@NullVoxPopuli I understand that, but won't restricting the node version in the package.json as in this PR cause package managers to complain about the node version when used with Node 14?

[chriskrycho]

That’s correct. I also think there are other options here, like pinning the rollup-plugin-TS version or even using alternative publishing mechanics (nothing about the v2 addon spec requires using rollup to get the output!). If there’s a problem with that particular tool we’re free not to use it; basically any publishing pipeline—built on rollup or otherwise—can relatively straightforwardly do what we need here; heck, this particular package could probably be built just using tsc if we so desired!

[NullVoxPopuli]

but won't restricting the node version in the package.json as in this PR cause package managers to complain about the node version when used with Node 14?

only if we release before the v2 conversion is complete -- I'd just remove the engines entry -- it's all much easier to demonstrate in the all-in-one v2 conversion PR.

doing the PRs piecemeal isn't exactly coherent 😅

also think there are other options here,

there is no need. We just don't need to specify engines in the package.json.

node is 100% irrelevant for consumers.
The only place node should show up is in the volta config

[NullVoxPopuli]

I updated the PR title to be more reflective of what's going on / the plan when it comes to v2 conversions

[NullVoxPopuli]

this will be removed when I do the v2 conversion. no need for engines

[kategengler]

I don't see the point of merging a change that cannot be released

[NullVoxPopuli]

We can't do an incremental migration to a v2 addon and have the main branch always be in a releasable state....

I can do a mega PR, if that's easier...

[chriskrycho]

@NullVoxPopuli your current approach with splitting it up is fine.

@kategengler we do this all the time for "up next" kinds of branches, and it's literally no different from shipping an Ember major. Indeed: we'll do the exact same thing we would on Ember itself here: master becomes the branch for the next major, and if we ID things that need back-porting we'll create a release-2-x branch and do the usual back port dance.

[kategengler]

@chriskrycho I agree we do this is in some projects, but most addons release from master and release much frequently. think it is fine, so long as anybody that may release knows that master is not in a release-able state.

[kategengler]

If you released this change CLI would not be able to update the addon, and anybody on Node 14 that took the update would get an error. Seems pretty broken to me? As @NullVoxPopuli said, the intention is this part of the change is never released.

[kategengler]

@NullVoxPopuli I don't think we need a multi-branch workflow for most addons. I think this is a special case because of engines and the CLI node policy. Except for policy-based things such as that, the main branch being releasable is enforced by CI. Personally, I would have left the less restrictive engines and just changed the development version of Node to make the move to a v2 addon so there wouldn't be a change that "we need to remember to undo". This is fine to move forward, we just need to remember to undo the engines change.

[NullVoxPopuli]

My plan was was to remove engines entirely, in the 4th PR in this series

1. (this one)
2. the pnpm one, because yarn and peers don't work (I have evidence if you need it, also yarn doesn't even support yarn... so...)
3. test-app split
4. v2 addon and engines removal

[chriskrycho]

@NullVoxPopuli FWIW although I merged this to keep a logjam, I think the better move here (and I should have thought of this!) was: bump the Volta version while leaving engines alone until that 4th PR. That's what we do in Glint for a variety of reasons. Let's keep that in mind for future reference.

[NullVoxPopuli]

Will do, for future addons, I'll do this series of PRs:

0. bump volta
1. pnpm
2. test-app split
3. v2 addon migration and engines removal