@bobfrankston/npmglobalize 1.0.236 → 1.0.237

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/README.md +1 -1
  2. package/lib.js +17 -6
  3. package/package.json +1 -1
package/README.md CHANGED
@@ -527,7 +527,7 @@ not what you meant to publish, so npmglobalize lists the conflicted files and st
527
527
  Example: -npm public,ts
528
528
  ```
529
529
 
530
- Flipping an already-published package between private and public runs `npm access set`. Since Aug 2026 that fails with a bare 403 when the token in `.npmrc` is a bypass-2FA granular token (npm no longer lets such tokens change package access, and offers no OTP prompt). npmglobalize recognizes that case, says so, and points at the package's Access page on npmjs.com (`https://www.npmjs.com/package/<name>/access`, browser sign-in with 2FA); set the status there and rerun. The finding is repeated in the Issues Summary. Publishing itself is unaffected until the Jan 2027 phase of the same deprecation. (2026-09-23)
530
+ Flipping an already-published package between private and public runs `npm access set`. Since Aug 2026 that fails with a bare 403 when the token in `.npmrc` is a bypass-2FA granular token (npm no longer lets such tokens change package access, and offers no OTP prompt). npmglobalize recognizes that case, says so, and points at the package's Access page on npmjs.com (`https://www.npmjs.com/package/<name>/access`, browser sign-in with 2FA); set the status there and rerun. The failed flip does not stop the publish: the package still goes up with the access npm currently has (the run says so, and the summary reports that access, not the requested one), and the requested visibility stays in `.globalize.json5` so the next run tries the flip again. The finding is repeated in the Issues Summary. Publishing itself is unaffected until the Jan 2027 phase of the same deprecation. (2026-09-23)
531
531
 
532
532
  `ts` is already the default on git (source is tracked). Pass `-npm ts` to ship
533
533
  the same files to npm — useful for debugging installed packages or "source on
package/lib.js CHANGED
@@ -8005,8 +8005,14 @@ export async function globalize(cwd, options = {}, configOptions = {}) {
8005
8005
  if (accessResult.stderr.trim())
8006
8006
  console.error(colors.dim(accessResult.stderr.trim()));
8007
8007
  console.error(colors.red(explainAccessChangeFailure(pkg.name, 'restricted', accessResult)));
8008
- if (!force)
8009
- return false;
8008
+ // 2026-09-23 01:20 EDT — Claude Code (Fable 5.1), Bob: "even if public fails
8009
+ // the npm store should still be updated". A failed flip no longer aborts the
8010
+ // publish: the package goes up with the access npm currently has, and
8011
+ // effectiveNpmVisibility is downgraded to match so the publish args and the
8012
+ // summaries report what actually happened. The requested visibility stays in
8013
+ // .globalize.json5, so the next run tries the flip again.
8014
+ effectiveNpmVisibility = 'public';
8015
+ console.log(colors.yellow(`Publishing ${pkg.name} as PUBLIC anyway (its current npm status); set it to private on the website, then rerun.`));
8010
8016
  }
8011
8017
  }
8012
8018
  else {
@@ -8014,7 +8020,8 @@ export async function globalize(cwd, options = {}, configOptions = {}) {
8014
8020
  }
8015
8021
  }
8016
8022
  // Don't set "private": true in package.json - that blocks all publishing
8017
- console.log(`Package '${pkg.name}' will publish as PRIVATE (restricted access).`);
8023
+ if (effectiveNpmVisibility === 'private')
8024
+ console.log(`Package '${pkg.name}' will publish as PRIVATE (restricted access).`);
8018
8025
  }
8019
8026
  else if (effectiveNpmVisibility === 'public') {
8020
8027
  // User explicitly wants public (or confirmed via prompt)
@@ -8032,15 +8039,19 @@ export async function globalize(cwd, options = {}, configOptions = {}) {
8032
8039
  if (accessResult.stderr.trim())
8033
8040
  console.error(colors.dim(accessResult.stderr.trim()));
8034
8041
  console.error(colors.red(explainAccessChangeFailure(pkg.name, 'public', accessResult)));
8035
- if (!force)
8036
- return false;
8042
+ // 2026-09-23 01:20 EDT — Claude Code (Fable 5.1), Bob: "even if public fails
8043
+ // the npm store should still be updated". Publish with the access npm has now
8044
+ // (restricted); no --access public is passed and the summaries say PRIVATE. The
8045
+ // requested visibility stays in .globalize.json5 so the next run retries the flip.
8046
+ effectiveNpmVisibility = 'private';
8047
+ console.log(colors.yellow(`Publishing ${pkg.name} as PRIVATE anyway (its current npm status); set it to public on the website, then rerun.`));
8037
8048
  }
8038
8049
  }
8039
8050
  else {
8040
8051
  console.log(colors.dim(` [dry-run] Would run: npm access set status=public ${pkg.name}`));
8041
8052
  }
8042
8053
  }
8043
- if (!publicConfirmed) {
8054
+ if (!publicConfirmed && effectiveNpmVisibility === 'public') {
8044
8055
  console.log(`Will publish '${pkg.name}' to PUBLIC npm registry.`);
8045
8056
  if (pkg.bin) {
8046
8057
  console.log(colors.yellow(` CLI tool - to install globally: npm install -g ${pkg.name}`));
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@bobfrankston/npmglobalize",
3
- "version": "1.0.236",
3
+ "version": "1.0.237",
4
4
  "description": "Transform file: dependencies to npm versions for publishing",
5
5
  "main": "index.js",
6
6
  "type": "module",