-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
fix(release): only add nx-release-publish to public packages #21338
Changes from 2 commits
f46d77c
331dd46
61a7a9b
a4596ed
80358f5
acd3362
f3f1c37
c2fb4ac
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,6 @@ | ||
#!/usr/bin/env node | ||
import { createProjectGraphAsync, workspaceRoot } from '@nx/devkit'; | ||
import { execSync } from 'node:child_process'; | ||
import { rmSync, writeFileSync } from 'node:fs'; | ||
import { rmSync } from 'node:fs'; | ||
import { join } from 'node:path'; | ||
import { URL } from 'node:url'; | ||
import { isRelativeVersionKeyword } from 'nx/src/command-line/release/utils/semver'; | ||
|
@@ -116,36 +115,6 @@ const LARGE_BUFFER = 1024 * 1000000; | |
if (options.dryRun) { | ||
console.warn('Not Publishing because --dryRun was passed'); | ||
} else { | ||
// If publishing locally, force all projects to not be private first | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is removed because There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No it’s because we agreed that the only workaround for this now was to manually set the targets instead, so I went to do that and realised we don’t have any private projects. If you want me to restore it in case we ever do something like that again in the future I can There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have restored the behaviour in case we ever need it again in future, and updated the log message to more explicitly cover the fact that a target will now need to be added manually for the private packages |
||
if (options.local) { | ||
console.log( | ||
'\nPublishing locally, so setting all resolved packages to not be private' | ||
); | ||
const projectGraph = await createProjectGraphAsync(); | ||
for (const proj of Object.values(projectGraph.nodes)) { | ||
if (proj.data.targets?.['nx-release-publish']) { | ||
const packageJsonPath = join( | ||
workspaceRoot, | ||
proj.data.targets?.['nx-release-publish']?.options.packageRoot, | ||
'package.json' | ||
); | ||
try { | ||
const packageJson = require(packageJsonPath); | ||
if (packageJson.private) { | ||
console.log( | ||
'- Publishing private package locally:', | ||
packageJson.name | ||
); | ||
writeFileSync( | ||
packageJsonPath, | ||
JSON.stringify({ ...packageJson, private: false }) | ||
); | ||
} | ||
} catch {} | ||
} | ||
} | ||
} | ||
|
||
const distTag = determineDistTag(options.version); | ||
|
||
// Run with dynamic output-style so that we have more minimal logs by default but still always see errors | ||
|
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.
Could this have been thrown as an error? It's quite a lengthy message but since we have a programmatic API, it's weird for their process to suddenly exit after calling the function without a chance to
catch
it?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.
Yes fair point, it would block programmatic consumers. We don’t have handleErrors in use in this command so I’ll double check the experience tomorrow
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.
So the way I have decided to handle this is leverage the handleErrors function for the CLI usage like we do for the other subcommands, but additionally have an appreciation for whether or not the code is being run via the CLI.
This allows us to keep the CLI error messaging focused on the publish run (where there are no other config errors), instead of having the runCommand failure and then another error message afterwards just reiterating that publishing has failed.
E.g. what I have gone for
vs
no appreciation for how it's being run via the CLI