-
Notifications
You must be signed in to change notification settings - Fork 7
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
RN-569 Upgrade yarn to v3 #3994
Conversation
7ec1cb6
to
96207f0
Compare
"refresh-database": "yarn workspace @tupaia/database refresh-database --root ../../", | ||
"test-all": "node ./scripts/node/testAll --silent", | ||
"validate": "./scripts/bash/validate.sh" | ||
"validate": "./scripts/bash/validate.sh", | ||
"package:build:ts": "cd $INIT_CWD && tsc -p tsconfig-build.json", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Scripts with colon can be called from any workspace. Combined with $INIT_CWD which is the workspace calling the script, we can reuse scripts in our workspaces. The other handy thing about this is that via this invocation, yarn loads root level npm packages, so each package doesn't need to have a copy of e.g. eslint declared as a devDependency.
See https://yarnpkg.com/getting-started/qa#how-to-share-scripts-between-workspaces
--
Edit: yarn run
performance was quite slow, so I changed build
scripts to use npm run --prefix ../../
instead. The others still use yarn x
for consistency and compatibility. This is a bit inconsistent, but I will keep an eye on the issue and when it's resolved we will change everything back to yarn x
again.
"test:coverage": "yarn test --coverage" | ||
}, | ||
"devDependencies": { | ||
"npm-run-all": "^4.1.5" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With Yarn2+, each package must explicitly declare its dependencies.
See https://yarnpkg.com/features/workspaces/#what-does-it-mean-to-be-a-workspace
"start-dev": "../../scripts/bash/backendStartDev.sh 9999", | ||
"start-verbose": "LOG_LEVEL=debug npm run start-dev", | ||
"start-dev": "yarn package:start:backend-start-dev 9999", | ||
"start-verbose": "LOG_LEVEL=debug yarn start-dev", | ||
"test": "yarn workspace @tupaia/database check-test-database-exists && DB_NAME=tupaia_test mocha", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Packages which use non-standard scripts e.g. mocha declare them manually and have those dependencies explicitly specified. It's also a good push to move away from non-standard stuff.
@@ -43,6 +51,8 @@ RUN mkdir -p ./packages/data-lake-api | |||
COPY packages/data-lake-api/package.json ./packages/data-lake-api | |||
RUN mkdir -p ./packages/database | |||
COPY packages/database/package.json ./packages/database | |||
RUN mkdir -p ./packages/devops |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found that omitting some packages gives a different lockfile in Yarn2+, which means that the yarn install --frozen-lockfile
below would fail, because it would want to change the lockfile. So I added them anyway. Adding these has no impact on CI/CD.
@@ -3,7 +3,7 @@ | |||
* Copyright (c) 2017 - 2020 Beyond Essential Systems Pty Ltd | |||
* | |||
*/ | |||
import { formatDateForApi, roundStartEndDates } from '@tupaia/ui-components/lib/chart'; | |||
import { formatDateForApi, roundStartEndDates } from '@tupaia/ui-components'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With ui-components no longer using rollup, I changed these to normal imports.
Rollup is not needed because the tree shaking it was used for is handled by the frontends (react-scripts build), the final build size of our frontends is the same, e.g. web-frontend was 20MB, and it is still 20MB.
@@ -26,5 +26,11 @@ module.exports = { | |||
loose: true, | |||
}, | |||
], | |||
[ | |||
'@babel/plugin-proposal-private-property-in-object', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixes annoying console output spam:
[ui-components] Though the "loose" option was set to "false" in your @babel/preset-env config, it will not be used for @babel/plugin-proposal-private-property-in-object since the "loose" mode option was set to "true" for @babel/plugin-proposal-class-properties.
[ui-components] The "loose" option must be the same for @babel/plugin-proposal-class-properties, @babel/plugin-proposal-private-methods and @babel/plugin-proposal-private-property-in-object (when they are enabled): you can silence this warning by explicitly adding
[ui-components] ["@babel/plugin-proposal-private-property-in-object", { "loose": true }]
[ui-components] to the "plugins" section of your Babel config.
"faker": "^4.1.0", | ||
"fast-glob": "^3.2.5", | ||
"jsoneditor": "^9.0.0", | ||
"moment": "^2.29.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had a setup I don't understand here where some dependencies were marked as devDependencies
even though they were actually used throughout src. Not sure how it worked before. I moved these to normal dependencies
, and the final build size of our frontends is the same, e.g. web-frontend was 20MB, and it is still 20MB.
1923201
to
8772d37
Compare
@@ -149,7 +149,7 @@ const NoDataTooltip = ({ payload, periodGranularity }) => { | |||
); | |||
}; | |||
|
|||
export const Tooltip = props => { | |||
export const ChartTooltip = props => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had a couple different Tooltip
s and three different Table
s in this package, all being exported at root level, causing errors when importing. I renamed them.
This is a change from Yarn1 to Yarn2: "Only the dependencies depended upon by a workspace can be accessed". see https://yarnpkg.com/features/workspaces/#what-does-it-mean-to-be-a-workspace
The latest cypress/base docker image has node 14.19.0
This differentiates it from the normal build script, which is used for production releases. Typically we only want to build to a state where a developer can start work, or tests can be run on a package etc. One direct advantage is that admin panel no longer does a production build after each yyarn install.
2f13a2a
to
9f55ad1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@IgorNadj That's a chuck of works, nice one! Thanks for the e2e testing new package and some dependencies clean up, the chart makes me can't wait to use the Yarn new version.
Got a few small questions but it looks great overall.
packages/web-frontend/package.json
Outdated
"build:desktop": "SKIP_PREFLIGHT_CHECK=true BUILD_PATH='./build/desktop/' GENERATE_SOURCEMAP=false react-scripts build", | ||
"build:mobile": "SKIP_PREFLIGHT_CHECK=true BUILD_PATH='./build/mobile/' GENERATE_SOURCEMAP=false REACT_APP_APP_TYPE=mobile react-scripts build", | ||
"build:desktop": "BUILD_PATH='./build/desktop/' yarn package:build:react-scripts", | ||
"build:mobile": "BUILD_PATH='./build/mobile/' yarn package:build:react-scripts", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we keep REACT_APP_APP_TYPE=mobile
GENERATE_SOURCEMAP=false
and SKIP_PREFLIGHT_CHECK=true
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good spotting on REACT_APP_APP_TYPE=mobile!
The other two env vars are set in package:build:react-scripts
@@ -16,6 +16,7 @@ | |||
"private": true, | |||
"scripts": { | |||
"build": "yarn package:build:ts", | |||
"build-dev": "yarn build-dev", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should it be:
"build-dev": "yarn build"
Or we want to skip this package during internal build?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like an old version of this PR, this is fixed in latest version.
@billli0 I'm not sure if you reviewed an older version of this PR sorry, just pinged you to take a new look, thanks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
Hey @IgorNadj I just wanted to mention for awareness that although tree shaking wasn't working well with rollup, bundling map and chart components separately was useful for saving bundle size in projects that do not use them such as PSSS and admin panel. I think those projects are not critical compared to Tupaia so I'm not worried about it. I think it could be a good idea to split out the chart components and map components into seperate packages in the mono-repo which would make this irrelevant anyway. There is an old ticket which includes this but it never got picked up. I'd be interested to hear if you agree and if so I might update that ticket. |
Issue #RN-569
Changes:
@tupaia/package/some/file
Outstanding issues
yarn run
yarnpkg/berry#2575npm run x
instead ofyarn x
for builds, this saves around 4 seconds per invocation, and because we use chaining quite a bit this saves a lot of time.Performance tests