Node 14 #1050
Merged
Node 14 #1050
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ct and deployment of the google cloud functions
…-lock.json differences
… transpillation and babel from the project (note: Jest doesn't support ecma modules well yet, still requires babel as a peer dependency for tests to work)
…mation bugs (might not have been worth the conversion, but for now I'm leaning towards consistency)
…g that it's a CommonJS module
…nd server babel set up to include babel-plugin-transform-import-meta
…e, not something I want to tangle with in this branch
|
New CI images a much larger, fingers crossed the impact on CI job spin up isn't too great. |
…flag for prod builds... because, after everything, turns out that was STILL broken
…ak in client/.eslintrc.json
…rom local node_modules rather than requiring it to be installed globally
…kage.json. Didn't want to, since they're really only needed for the deploy scripts (which aren't run through package.json), but it's the most trustworthy way to run the local bode_modules babel in CI (since npx isn't installed)
…r step, so that the function will redeploy on transiplation config change
…ud sdk image, shouldn't be trying to run babel in there. Lift server transpile up in to the main build job, persist to the workspace with everything else
… plugin-transform-modules-commonjs is part of preset-env by default
…o declare that the modules are CommonJS rather than esModules
…t with the property app...
…ack in to bash scripts alongside the other deploy-specific scripts for those projects
…int for it (and catch some other misc unlinted lines in client/src)
|
... had hoped this would be the time we could fully standardize on esModules, but:
|
…See PR 1050 for notes on what prevents this from being an option
…odules. See PR 1050 for notes on what prevents this from being an option" This reverts commit 2c4b038.
|
Well, minor victory, since the local |
ktw1016
approved these changes
Apr 30, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Move entire project to Node 14, both as the expected dev environment and as the intended target for Google Cloud Function deploys. Move node-targeted code to esModules where possible.
Have yet to see client builds hitting memory limits after switching to Node 14 🤞. Edit: still true locally, where it seems the problem had always been the baked in memory limits of the older V8 I was still on. Still very easy to burn through the CI container's 4GB, but I've re-re-fixed the prod build memory capping in this branch and I think I've got CI surviving the build jobs consistently.