Upgrade node requirement to >= 10
#794
Assignees
Labels
ops-excellence
Operational Excellence
Comments
RomainMuller
added a commit
that referenced
this issue
Sep 18, 2019
As `node 8` is becoming EOL soon, we're upgrading the baseline `node` version requirement from `>= 8.10.0` to `>= 10.0.0`. At this point, the code generation is not affected, but this our first signal to consumers that they need to upgrade their runtimes and/or codebases. Additionally, normalized the order of fields in the `package.json` files to make it nicer for people to work in the mono-repo. Related to #794
RomainMuller
added a commit
that referenced
this issue
Sep 18, 2019
As `node 8` is becoming EOL soon, we're upgrading the baseline `node` version requirement from `>= 8.10.0` to `>= 10.0.0`. At this point, the code generation is not affected, but this our first signal to consumers that they need to upgrade their runtimes and/or codebases. Additionally, normalized the order of fields in the `package.json` files to make it nicer for people to work in the mono-repo. Related to #794
mergify bot
pushed a commit
that referenced
this issue
Sep 19, 2019
* feat: configure `engines` with `node >= 10.0.0` As `node 8` is becoming EOL soon, we're upgrading the baseline `node` version requirement from `>= 8.10.0` to `>= 10.0.0`. At this point, the code generation is not affected, but this our first signal to consumers that they need to upgrade their runtimes and/or codebases. Additionally, normalized the order of fields in the `package.json` files to make it nicer for people to work in the mono-repo. Related to #794 * fix broken tests, bump minimal node to 10.3.0 * Update CONTRIBUTING.md
RomainMuller
added a commit
that referenced
this issue
Oct 17, 2019
Actually upgrade the `node` engine support to 10.x tree, as has been declared in the `package.json` files for a month now. Additionally, standardized the `compilerOptions` in the `tsconfig.json` files that are *not* generated by `jsii`, in order to use `ES2018` standard library, enable `strict` mode (this includes `strictPropertyInitialization`, which was not enabled previously and required a few code changes in `jsii-pacmak` that were made ad-minima). The library clause of `tsconfig.json` files that are generated by `jsii` has not been changed yet. This means you need to use `node >= 10.x` in order to use `jsii`, but you cannot use it to build code that depend on APIs that are not yet available in `node 8`. This behavior will be updated in a second phase. Related: #794
mergify bot
pushed a commit
that referenced
this issue
Oct 18, 2019
Actually upgrade the `node` engine support to 10.x tree, as has been declared in the `package.json` files for a month now. Additionally, standardized the `compilerOptions` in the `tsconfig.json` files that are *not* generated by `jsii`, in order to use `ES2018` standard library, enable `strict` mode (this includes `strictPropertyInitialization`, which was not enabled previously and required a few code changes in `jsii-pacmak` that were made ad-minima). The library clause of `tsconfig.json` files that are generated by `jsii` has not been changed yet. This means you need to use `node >= 10.x` in order to use `jsii`, but you cannot use it to build code that depend on APIs that are not yet available in `node 8`. This behavior will be updated in a second phase. Related: #794
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As node 8 is going to be EOL soon (by the end of this year), we need to raise our baseline node requirement to be
>= 10. This will also enable increasing our@types/nodedependency as well as set ourtsctarget toES2018.package.jsonfiles@types/nodedependency to the^10.0.0treetsconfig.jsontargets toES2018(to generate more compact/efficient JS)The text was updated successfully, but these errors were encountered: