-
Notifications
You must be signed in to change notification settings - Fork 1
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
use 'npm ci' instead of 'npm install' for frontend builds #48
Comments
It may be worth prioritizing the Rationale being if we only change the CI in individual MFEs to run I think it may make sense to tackle tubular first and then the individual MFEs. |
we are overriding(e.g.) header and footer packages with NPM aliases using edx-internal configuration. Since |
@abdullahwaheed I believe only the The latter install for NPM alias overrides does not read from package.json or package-lock.json; it just installs over whatever default package was installed in package-lock.json for the repo. Replicating the build process in GoCD locally works without error, e.g.: npm ci
npm install @edx/brand@npm:@edx/brand-edx.org@2 Technically, that latter install will modify the package-lock.json file, but those changes are local to GoCD during the build + deploy process and never committed back to the repo. We could prevent the latter |
@adamstankiewicz thank you for clarification. You are right, i have missed the part where we are using package installation and alias installation separately. |
What's the current status of this one? |
Its PR is ready for review |
Looks like tubular is on its way out from the openedx org. Plus, the PR is merged. Closing. |
The gocd generated pipelines use 'npm install' rather than 'npm ci', thanks to tubular/scripts/frontend_build.py and frontend_utils- see here: https://github.com/edx/tubular/blob/master/tubular/scripts/frontend_utils.py#L59
'npm ci' is preferable, as it is more strict about reproducing the package versions set in the package-lock.json (whereas 'npm install' blows it away and can use different versions).
Phil Shiu and David Joy have discussed that this should be corrected to npm ci. Logging here for tracking/info, since it affects many MFEs.
The text was updated successfully, but these errors were encountered: