[BUG] regression, npm publish folder has a new and completely incompatible behaviour where folder is interpreted as a package name and is then fetched from the registry #4126

Description

@cormacrelf

Is there an existing issue for this?

  • I have searched the existing issues

This issue exists in the latest npm version

  • I am using the latest npm

Current Behavior

npm publish folder syntax has stopped working almost completely if the folder is not prefixed with a ./ and is not an absolute path. Not only has it stopped working, it is doing utter nonsense, and is producing really weird output as outlined in the repro section below. So much so it no longer appears to be doing anything recognisable as publishing a package at all.

This is a rather critical piece of functionality that is going to break a bunch of scripts all over the internet. I personally found this bug when an unchanged Github Actions workflow stopped publishing canary builds of my package.

The syntax I have used there is npm publish dist --access public --tag canary. The package has been built correctly into a directory named dist, and it has a package.json with a name (that is not dist but @citeproc-rs/wasm). For the past year, this script successfully published dozens of versions of the package, but today it does not. It now fails with an ETARGET message, saying that the package/version dist@canary could not be found. This is completely unexpected, not only because it worked before, but because there is no documented syntax of npm publish where any command line argument accepts a package name. That has always been implied from the package.json!

The Steps to Reproduce below has a guided tour of the insanity that is going on with npm publish.

Expected Behavior

npm publish folder should publish a folder!!! Even if that were not literally the documented syntax of the command, you would expect it to fail with a mysterious error message like ETARGET or a 404. There is no such documented syntax npm publish packagename! Why would it try looking it up on the registry!!!

Steps To Reproduce

  1. mkdir folder
  2. Put a package.json inside it, with "name": "asdfasdfasdf-nonexistent-package"
  3. Observe that the documentation says the syntax is npm publish [<tarball>|<folder>], no mention of folder being a package name
  4. Attempt npm publish folder --dry-run with npm 8.2.0

Watch, in horror, as NPM appears to download the tarball for package folder@0.0.4, list out its contents, and print the summary of the tarball. There is zero relation between doing this and npm publish. I am absolutely speechless.

npm notice
npm notice 📦 folder@0.0.4
npm notice === Tarball Contents ===
npm notice 14B .npmignore
npm notice 263B README.md
npm notice 4.9kB lib/html.js
npm notice 2.8kB lib/index.js
npm notice 321B package.json
...
npm notice === Tarball Details ===
npm notice name: folder
npm notice version: 0.0.4
npm notice filename: folder-0.0.4.tgz
npm notice package size: 206.8 kB
npm notice unpacked size: 226.1 kB
npm notice shasum: 56dc666bd686e2f029055e938a003f0f2fadc225
npm notice integrity: sha512-drevPjCcenZ7O[...]monYcuEYiMK3A==
npm notice total files: 146
npm notice
+ folder@0.0.4

It goes on. The behaviour is different if the name of the directory is not an existing package in the registry.

  1. mv folder asdfasdfasdf-nonexistent-package
  2. npm publish asdfasdfasdf-nonexistent-package --dry-run

Receive:

npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/asdfasdfasdf-nonexistent-package - Not found
npm ERR! 404
npm ERR! 404 'asdfasdfasdf-nonexistent-package@latest' is not in this registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

There's a THIRD variation. This is when the name of the folder is an existing package on the registry, but you're using the --tag flag, and the package of that name (again, COMPLETELY irrelevant, NPM should not be looking it up at all) does not have that tag. It is relevant to post here because you get more completely different output.

  1. Rename the directory back to folder
  2. npm publish folder --dry-run --tag canary
npm ERR! code ETARGET
npm ERR! notarget No matching version found for folder@canary.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

There is a workaround: use the syntax npm publish ./folder. Then it knows the folder is a folder.

Environment

  • npm: v8.2.0
  • Node: v17.0.1
  • OS: macOS 12.0.1
  • platform: Macbook Pro
  • npm config:
; "builtin" config from /opt/homebrew/lib/node_modules/npm/npmrcprefix = "/opt/homebrew"; "user" config from /Users/me/.npmrc
//registry.npmjs.org/:_authToken = (protected)
; node bin location = /opt/homebrew/Cellar/node/17.0.1/bin/node; cwd = /Users/me/git/temporary; HOME = /Users/me; Run `npm config ls -l` to show all defaults

Metadata

Metadata

Assignees

Labels

Bugthing that needs fixingDiscusswill be discussed at the next internal callPriority 0will get attention right awayRelease 8.xwork is associated with a specific npm 8 release

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    , 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all
     blocks
    (function() {
    function addCopyButtons() {
    document.querySelectorAll('pre code').forEach(function(codeBlock) {
    if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
    codeBlock.parentElement.setAttribute('data-copy-added', 'true');
    var btn = document.createElement('button');
    btn.textContent = 'Copy';
    btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
    btn.onmouseover = function() { this.style.opacity = '1'; };
    btn.onmouseout = function() { this.style.opacity = '0.7'; };
    btn.onclick = function() {
    navigator.clipboard.writeText(codeBlock.textContent).then(function() {
    btn.textContent = 'Copied!';
    setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
    });
    };
    codeBlock.parentElement.style.position = 'relative';
    codeBlock.parentElement.appendChild(btn);
    });
    }
    addCopyButtons();
    // Re-run on dynamic content
    var observer = new MutationObserver(addCopyButtons);
    observer.observe(document.body, { childList: true, subtree: true });
    })();
    }
    } catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
    })();
    (function(){
    try {
    var __m = "github.com";
    var __re = new RegExp('^' + "github\\.com" + '
    
    Skip to content

    [BUG] regression, npm publish folder has a new and completely incompatible behaviour where folder is interpreted as a package name and is then fetched from the registry #4126

    Description

    @cormacrelf

    Is there an existing issue for this?

    • I have searched the existing issues

    This issue exists in the latest npm version

    • I am using the latest npm

    Current Behavior

    npm publish folder syntax has stopped working almost completely if the folder is not prefixed with a ./ and is not an absolute path. Not only has it stopped working, it is doing utter nonsense, and is producing really weird output as outlined in the repro section below. So much so it no longer appears to be doing anything recognisable as publishing a package at all.

    This is a rather critical piece of functionality that is going to break a bunch of scripts all over the internet. I personally found this bug when an unchanged Github Actions workflow stopped publishing canary builds of my package.

    The syntax I have used there is npm publish dist --access public --tag canary. The package has been built correctly into a directory named dist, and it has a package.json with a name (that is not dist but @citeproc-rs/wasm). For the past year, this script successfully published dozens of versions of the package, but today it does not. It now fails with an ETARGET message, saying that the package/version dist@canary could not be found. This is completely unexpected, not only because it worked before, but because there is no documented syntax of npm publish where any command line argument accepts a package name. That has always been implied from the package.json!

    The Steps to Reproduce below has a guided tour of the insanity that is going on with npm publish.

    Expected Behavior

    npm publish folder should publish a folder!!! Even if that were not literally the documented syntax of the command, you would expect it to fail with a mysterious error message like ETARGET or a 404. There is no such documented syntax npm publish packagename! Why would it try looking it up on the registry!!!

    Steps To Reproduce

    1. mkdir folder
    2. Put a package.json inside it, with "name": "asdfasdfasdf-nonexistent-package"
    3. Observe that the documentation says the syntax is npm publish [<tarball>|<folder>], no mention of folder being a package name
    4. Attempt npm publish folder --dry-run with npm 8.2.0

    Watch, in horror, as NPM appears to download the tarball for package folder@0.0.4, list out its contents, and print the summary of the tarball. There is zero relation between doing this and npm publish. I am absolutely speechless.

    npm notice
    npm notice 📦 folder@0.0.4
    npm notice === Tarball Contents ===
    npm notice 14B .npmignore
    npm notice 263B README.md
    npm notice 4.9kB lib/html.js
    npm notice 2.8kB lib/index.js
    npm notice 321B package.json
    ...
    npm notice === Tarball Details ===
    npm notice name: folder
    npm notice version: 0.0.4
    npm notice filename: folder-0.0.4.tgz
    npm notice package size: 206.8 kB
    npm notice unpacked size: 226.1 kB
    npm notice shasum: 56dc666bd686e2f029055e938a003f0f2fadc225
    npm notice integrity: sha512-drevPjCcenZ7O[...]monYcuEYiMK3A==
    npm notice total files: 146
    npm notice
    + folder@0.0.4
    

    It goes on. The behaviour is different if the name of the directory is not an existing package in the registry.

    1. mv folder asdfasdfasdf-nonexistent-package
    2. npm publish asdfasdfasdf-nonexistent-package --dry-run

    Receive:

    npm ERR! code E404
    npm ERR! 404 Not Found - GET https://registry.npmjs.org/asdfasdfasdf-nonexistent-package - Not found
    npm ERR! 404
    npm ERR! 404 'asdfasdfasdf-nonexistent-package@latest' is not in this registry.
    npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
    npm ERR! 404
    npm ERR! 404 Note that you can also install from a
    npm ERR! 404 tarball, folder, http url, or git url.
    

    There's a THIRD variation. This is when the name of the folder is an existing package on the registry, but you're using the --tag flag, and the package of that name (again, COMPLETELY irrelevant, NPM should not be looking it up at all) does not have that tag. It is relevant to post here because you get more completely different output.

    1. Rename the directory back to folder
    2. npm publish folder --dry-run --tag canary
    npm ERR! code ETARGET
    npm ERR! notarget No matching version found for folder@canary.
    npm ERR! notarget In most cases you or one of your dependencies are requesting
    npm ERR! notarget a package version that doesn't exist.
    

    There is a workaround: use the syntax npm publish ./folder. Then it knows the folder is a folder.

    Environment

    • npm: v8.2.0
    • Node: v17.0.1
    • OS: macOS 12.0.1
    • platform: Macbook Pro
    • npm config:
    ; "builtin" config from /opt/homebrew/lib/node_modules/npm/npmrcprefix = "/opt/homebrew"; "user" config from /Users/me/.npmrc
    //registry.npmjs.org/:_authToken = (protected)
    ; node bin location = /opt/homebrew/Cellar/node/17.0.1/bin/node; cwd = /Users/me/git/temporary; HOME = /Users/me; Run `npm config ls -l` to show all defaults

    Metadata

    Metadata

    Assignees

    Labels

    Bugthing that needs fixingDiscusswill be discussed at the next internal callPriority 0will get attention right awayRelease 8.xwork is associated with a specific npm 8 release

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      , 'i'); if (__m === '*' || __re.test(location.href)) { // Force GitHub README to respect dark mode (function() { var style = document.createElement('style'); style.textContent = ' .markdown-body { color-scheme: dark light; } .markdown-body pre { background: #161b22 !important; } .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; } .markdown-body table th, .markdown-body table td { border-color: #30363d !important; } .markdown-body img { background: #0d1117; } .markdown-body blockquote { border-left-color: #8b949e; } .markdown-body hr { border-color: #30363d; } '; document.head.appendChild(style); })(); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
      Skip to content

      [BUG] regression, npm publish folder has a new and completely incompatible behaviour where folder is interpreted as a package name and is then fetched from the registry #4126

      Description

      @cormacrelf

      Is there an existing issue for this?

      • I have searched the existing issues

      This issue exists in the latest npm version

      • I am using the latest npm

      Current Behavior

      npm publish folder syntax has stopped working almost completely if the folder is not prefixed with a ./ and is not an absolute path. Not only has it stopped working, it is doing utter nonsense, and is producing really weird output as outlined in the repro section below. So much so it no longer appears to be doing anything recognisable as publishing a package at all.

      This is a rather critical piece of functionality that is going to break a bunch of scripts all over the internet. I personally found this bug when an unchanged Github Actions workflow stopped publishing canary builds of my package.

      The syntax I have used there is npm publish dist --access public --tag canary. The package has been built correctly into a directory named dist, and it has a package.json with a name (that is not dist but @citeproc-rs/wasm). For the past year, this script successfully published dozens of versions of the package, but today it does not. It now fails with an ETARGET message, saying that the package/version dist@canary could not be found. This is completely unexpected, not only because it worked before, but because there is no documented syntax of npm publish where any command line argument accepts a package name. That has always been implied from the package.json!

      The Steps to Reproduce below has a guided tour of the insanity that is going on with npm publish.

      Expected Behavior

      npm publish folder should publish a folder!!! Even if that were not literally the documented syntax of the command, you would expect it to fail with a mysterious error message like ETARGET or a 404. There is no such documented syntax npm publish packagename! Why would it try looking it up on the registry!!!

      Steps To Reproduce

      1. mkdir folder
      2. Put a package.json inside it, with "name": "asdfasdfasdf-nonexistent-package"
      3. Observe that the documentation says the syntax is npm publish [<tarball>|<folder>], no mention of folder being a package name
      4. Attempt npm publish folder --dry-run with npm 8.2.0

      Watch, in horror, as NPM appears to download the tarball for package folder@0.0.4, list out its contents, and print the summary of the tarball. There is zero relation between doing this and npm publish. I am absolutely speechless.

      npm notice
      npm notice 📦 folder@0.0.4
      npm notice === Tarball Contents ===
      npm notice 14B .npmignore
      npm notice 263B README.md
      npm notice 4.9kB lib/html.js
      npm notice 2.8kB lib/index.js
      npm notice 321B package.json
      ...
      npm notice === Tarball Details ===
      npm notice name: folder
      npm notice version: 0.0.4
      npm notice filename: folder-0.0.4.tgz
      npm notice package size: 206.8 kB
      npm notice unpacked size: 226.1 kB
      npm notice shasum: 56dc666bd686e2f029055e938a003f0f2fadc225
      npm notice integrity: sha512-drevPjCcenZ7O[...]monYcuEYiMK3A==
      npm notice total files: 146
      npm notice
      + folder@0.0.4
      

      It goes on. The behaviour is different if the name of the directory is not an existing package in the registry.

      1. mv folder asdfasdfasdf-nonexistent-package
      2. npm publish asdfasdfasdf-nonexistent-package --dry-run

      Receive:

      npm ERR! code E404
      npm ERR! 404 Not Found - GET https://registry.npmjs.org/asdfasdfasdf-nonexistent-package - Not found
      npm ERR! 404
      npm ERR! 404 'asdfasdfasdf-nonexistent-package@latest' is not in this registry.
      npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
      npm ERR! 404
      npm ERR! 404 Note that you can also install from a
      npm ERR! 404 tarball, folder, http url, or git url.
      

      There's a THIRD variation. This is when the name of the folder is an existing package on the registry, but you're using the --tag flag, and the package of that name (again, COMPLETELY irrelevant, NPM should not be looking it up at all) does not have that tag. It is relevant to post here because you get more completely different output.

      1. Rename the directory back to folder
      2. npm publish folder --dry-run --tag canary
      npm ERR! code ETARGET
      npm ERR! notarget No matching version found for folder@canary.
      npm ERR! notarget In most cases you or one of your dependencies are requesting
      npm ERR! notarget a package version that doesn't exist.
      

      There is a workaround: use the syntax npm publish ./folder. Then it knows the folder is a folder.

      Environment

      • npm: v8.2.0
      • Node: v17.0.1
      • OS: macOS 12.0.1
      • platform: Macbook Pro
      • npm config:
      ; "builtin" config from /opt/homebrew/lib/node_modules/npm/npmrcprefix = "/opt/homebrew"; "user" config from /Users/me/.npmrc
      //registry.npmjs.org/:_authToken = (protected)
      ; node bin location = /opt/homebrew/Cellar/node/17.0.1/bin/node; cwd = /Users/me/git/temporary; HOME = /Users/me; Run `npm config ls -l` to show all defaults

      Metadata

      Metadata

      Assignees

      Labels

      Bugthing that needs fixingDiscusswill be discussed at the next internal callPriority 0will get attention right awayRelease 8.xwork is associated with a specific npm 8 release

      Type

      No type

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions

        , 'i'); if (__m === '*' || __re.test(location.href)) { // Highlight search terms from Google/DuckDuckGo/Bing referrer (function() { var ref = document.referrer; var terms = []; if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) { var url = new URL(ref); var q = url.searchParams.get('q') || url.searchParams.get('p'); if (q) { terms = q.split(/\s+/).filter(function(t) { return t.length > 2; }); } } if (terms.length === 0) return; var style = document.createElement('style'); style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }'; document.head.appendChild(style); function highlight(node) { if (node.nodeType === 3) { // text node var text = node.textContent; var found = false; terms.forEach(function(term) { var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
        Skip to content

        [BUG] regression, npm publish folder has a new and completely incompatible behaviour where folder is interpreted as a package name and is then fetched from the registry #4126

        Description

        @cormacrelf

        Is there an existing issue for this?

        • I have searched the existing issues

        This issue exists in the latest npm version

        • I am using the latest npm

        Current Behavior

        npm publish folder syntax has stopped working almost completely if the folder is not prefixed with a ./ and is not an absolute path. Not only has it stopped working, it is doing utter nonsense, and is producing really weird output as outlined in the repro section below. So much so it no longer appears to be doing anything recognisable as publishing a package at all.

        This is a rather critical piece of functionality that is going to break a bunch of scripts all over the internet. I personally found this bug when an unchanged Github Actions workflow stopped publishing canary builds of my package.

        The syntax I have used there is npm publish dist --access public --tag canary. The package has been built correctly into a directory named dist, and it has a package.json with a name (that is not dist but @citeproc-rs/wasm). For the past year, this script successfully published dozens of versions of the package, but today it does not. It now fails with an ETARGET message, saying that the package/version dist@canary could not be found. This is completely unexpected, not only because it worked before, but because there is no documented syntax of npm publish where any command line argument accepts a package name. That has always been implied from the package.json!

        The Steps to Reproduce below has a guided tour of the insanity that is going on with npm publish.

        Expected Behavior

        npm publish folder should publish a folder!!! Even if that were not literally the documented syntax of the command, you would expect it to fail with a mysterious error message like ETARGET or a 404. There is no such documented syntax npm publish packagename! Why would it try looking it up on the registry!!!

        Steps To Reproduce

        1. mkdir folder
        2. Put a package.json inside it, with "name": "asdfasdfasdf-nonexistent-package"
        3. Observe that the documentation says the syntax is npm publish [<tarball>|<folder>], no mention of folder being a package name
        4. Attempt npm publish folder --dry-run with npm 8.2.0

        Watch, in horror, as NPM appears to download the tarball for package folder@0.0.4, list out its contents, and print the summary of the tarball. There is zero relation between doing this and npm publish. I am absolutely speechless.

        npm notice
        npm notice 📦 folder@0.0.4
        npm notice === Tarball Contents ===
        npm notice 14B .npmignore
        npm notice 263B README.md
        npm notice 4.9kB lib/html.js
        npm notice 2.8kB lib/index.js
        npm notice 321B package.json
        ...
        npm notice === Tarball Details ===
        npm notice name: folder
        npm notice version: 0.0.4
        npm notice filename: folder-0.0.4.tgz
        npm notice package size: 206.8 kB
        npm notice unpacked size: 226.1 kB
        npm notice shasum: 56dc666bd686e2f029055e938a003f0f2fadc225
        npm notice integrity: sha512-drevPjCcenZ7O[...]monYcuEYiMK3A==
        npm notice total files: 146
        npm notice
        + folder@0.0.4
        

        It goes on. The behaviour is different if the name of the directory is not an existing package in the registry.

        1. mv folder asdfasdfasdf-nonexistent-package
        2. npm publish asdfasdfasdf-nonexistent-package --dry-run

        Receive:

        npm ERR! code E404
        npm ERR! 404 Not Found - GET https://registry.npmjs.org/asdfasdfasdf-nonexistent-package - Not found
        npm ERR! 404
        npm ERR! 404 'asdfasdfasdf-nonexistent-package@latest' is not in this registry.
        npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
        npm ERR! 404
        npm ERR! 404 Note that you can also install from a
        npm ERR! 404 tarball, folder, http url, or git url.
        

        There's a THIRD variation. This is when the name of the folder is an existing package on the registry, but you're using the --tag flag, and the package of that name (again, COMPLETELY irrelevant, NPM should not be looking it up at all) does not have that tag. It is relevant to post here because you get more completely different output.

        1. Rename the directory back to folder
        2. npm publish folder --dry-run --tag canary
        npm ERR! code ETARGET
        npm ERR! notarget No matching version found for folder@canary.
        npm ERR! notarget In most cases you or one of your dependencies are requesting
        npm ERR! notarget a package version that doesn't exist.
        

        There is a workaround: use the syntax npm publish ./folder. Then it knows the folder is a folder.

        Environment

        • npm: v8.2.0
        • Node: v17.0.1
        • OS: macOS 12.0.1
        • platform: Macbook Pro
        • npm config:
        ; "builtin" config from /opt/homebrew/lib/node_modules/npm/npmrcprefix = "/opt/homebrew"; "user" config from /Users/me/.npmrc
        //registry.npmjs.org/:_authToken = (protected)
        ; node bin location = /opt/homebrew/Cellar/node/17.0.1/bin/node; cwd = /Users/me/git/temporary; HOME = /Users/me; Run `npm config ls -l` to show all defaults

        Metadata

        Metadata

        Assignees

        Labels

        Bugthing that needs fixingDiscusswill be discussed at the next internal callPriority 0will get attention right awayRelease 8.xwork is associated with a specific npm 8 release

        Type

        No type

        Projects

        No projects

          Milestone

          No milestone

          Relationships

          None yet

          Development

          No branches or pull requests

          Issue actions

          , 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
          Skip to content

          [BUG] regression, npm publish folder has a new and completely incompatible behaviour where folder is interpreted as a package name and is then fetched from the registry #4126

          Description

          @cormacrelf

          Is there an existing issue for this?

          • I have searched the existing issues

          This issue exists in the latest npm version

          • I am using the latest npm

          Current Behavior

          npm publish folder syntax has stopped working almost completely if the folder is not prefixed with a ./ and is not an absolute path. Not only has it stopped working, it is doing utter nonsense, and is producing really weird output as outlined in the repro section below. So much so it no longer appears to be doing anything recognisable as publishing a package at all.

          This is a rather critical piece of functionality that is going to break a bunch of scripts all over the internet. I personally found this bug when an unchanged Github Actions workflow stopped publishing canary builds of my package.

          The syntax I have used there is npm publish dist --access public --tag canary. The package has been built correctly into a directory named dist, and it has a package.json with a name (that is not dist but @citeproc-rs/wasm). For the past year, this script successfully published dozens of versions of the package, but today it does not. It now fails with an ETARGET message, saying that the package/version dist@canary could not be found. This is completely unexpected, not only because it worked before, but because there is no documented syntax of npm publish where any command line argument accepts a package name. That has always been implied from the package.json!

          The Steps to Reproduce below has a guided tour of the insanity that is going on with npm publish.

          Expected Behavior

          npm publish folder should publish a folder!!! Even if that were not literally the documented syntax of the command, you would expect it to fail with a mysterious error message like ETARGET or a 404. There is no such documented syntax npm publish packagename! Why would it try looking it up on the registry!!!

          Steps To Reproduce

          1. mkdir folder
          2. Put a package.json inside it, with "name": "asdfasdfasdf-nonexistent-package"
          3. Observe that the documentation says the syntax is npm publish [<tarball>|<folder>], no mention of folder being a package name
          4. Attempt npm publish folder --dry-run with npm 8.2.0

          Watch, in horror, as NPM appears to download the tarball for package folder@0.0.4, list out its contents, and print the summary of the tarball. There is zero relation between doing this and npm publish. I am absolutely speechless.

          npm notice
          npm notice 📦 folder@0.0.4
          npm notice === Tarball Contents ===
          npm notice 14B .npmignore
          npm notice 263B README.md
          npm notice 4.9kB lib/html.js
          npm notice 2.8kB lib/index.js
          npm notice 321B package.json
          ...
          npm notice === Tarball Details ===
          npm notice name: folder
          npm notice version: 0.0.4
          npm notice filename: folder-0.0.4.tgz
          npm notice package size: 206.8 kB
          npm notice unpacked size: 226.1 kB
          npm notice shasum: 56dc666bd686e2f029055e938a003f0f2fadc225
          npm notice integrity: sha512-drevPjCcenZ7O[...]monYcuEYiMK3A==
          npm notice total files: 146
          npm notice
          + folder@0.0.4
          

          It goes on. The behaviour is different if the name of the directory is not an existing package in the registry.

          1. mv folder asdfasdfasdf-nonexistent-package
          2. npm publish asdfasdfasdf-nonexistent-package --dry-run

          Receive:

          npm ERR! code E404
          npm ERR! 404 Not Found - GET https://registry.npmjs.org/asdfasdfasdf-nonexistent-package - Not found
          npm ERR! 404
          npm ERR! 404 'asdfasdfasdf-nonexistent-package@latest' is not in this registry.
          npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
          npm ERR! 404
          npm ERR! 404 Note that you can also install from a
          npm ERR! 404 tarball, folder, http url, or git url.
          

          There's a THIRD variation. This is when the name of the folder is an existing package on the registry, but you're using the --tag flag, and the package of that name (again, COMPLETELY irrelevant, NPM should not be looking it up at all) does not have that tag. It is relevant to post here because you get more completely different output.

          1. Rename the directory back to folder
          2. npm publish folder --dry-run --tag canary
          npm ERR! code ETARGET
          npm ERR! notarget No matching version found for folder@canary.
          npm ERR! notarget In most cases you or one of your dependencies are requesting
          npm ERR! notarget a package version that doesn't exist.
          

          There is a workaround: use the syntax npm publish ./folder. Then it knows the folder is a folder.

          Environment

          • npm: v8.2.0
          • Node: v17.0.1
          • OS: macOS 12.0.1
          • platform: Macbook Pro
          • npm config:
          ; "builtin" config from /opt/homebrew/lib/node_modules/npm/npmrcprefix = "/opt/homebrew"; "user" config from /Users/me/.npmrc
          //registry.npmjs.org/:_authToken = (protected)
          ; node bin location = /opt/homebrew/Cellar/node/17.0.1/bin/node; cwd = /Users/me/git/temporary; HOME = /Users/me; Run `npm config ls -l` to show all defaults

          Metadata

          Metadata

          Assignees

          Labels

          Bugthing that needs fixingDiscusswill be discussed at the next internal callPriority 0will get attention right awayRelease 8.xwork is associated with a specific npm 8 release

          Type

          No type

          Projects

          No projects

            Milestone

            No milestone

            Relationships

            None yet

            Development

            No branches or pull requests

            Issue actions

            , 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
            Skip to content

            [BUG] regression, npm publish folder has a new and completely incompatible behaviour where folder is interpreted as a package name and is then fetched from the registry #4126

            Description

            @cormacrelf

            Is there an existing issue for this?

            • I have searched the existing issues

            This issue exists in the latest npm version

            • I am using the latest npm

            Current Behavior

            npm publish folder syntax has stopped working almost completely if the folder is not prefixed with a ./ and is not an absolute path. Not only has it stopped working, it is doing utter nonsense, and is producing really weird output as outlined in the repro section below. So much so it no longer appears to be doing anything recognisable as publishing a package at all.

            This is a rather critical piece of functionality that is going to break a bunch of scripts all over the internet. I personally found this bug when an unchanged Github Actions workflow stopped publishing canary builds of my package.

            The syntax I have used there is npm publish dist --access public --tag canary. The package has been built correctly into a directory named dist, and it has a package.json with a name (that is not dist but @citeproc-rs/wasm). For the past year, this script successfully published dozens of versions of the package, but today it does not. It now fails with an ETARGET message, saying that the package/version dist@canary could not be found. This is completely unexpected, not only because it worked before, but because there is no documented syntax of npm publish where any command line argument accepts a package name. That has always been implied from the package.json!

            The Steps to Reproduce below has a guided tour of the insanity that is going on with npm publish.

            Expected Behavior

            npm publish folder should publish a folder!!! Even if that were not literally the documented syntax of the command, you would expect it to fail with a mysterious error message like ETARGET or a 404. There is no such documented syntax npm publish packagename! Why would it try looking it up on the registry!!!

            Steps To Reproduce

            1. mkdir folder
            2. Put a package.json inside it, with "name": "asdfasdfasdf-nonexistent-package"
            3. Observe that the documentation says the syntax is npm publish [<tarball>|<folder>], no mention of folder being a package name
            4. Attempt npm publish folder --dry-run with npm 8.2.0

            Watch, in horror, as NPM appears to download the tarball for package folder@0.0.4, list out its contents, and print the summary of the tarball. There is zero relation between doing this and npm publish. I am absolutely speechless.

            npm notice
            npm notice 📦 folder@0.0.4
            npm notice === Tarball Contents ===
            npm notice 14B .npmignore
            npm notice 263B README.md
            npm notice 4.9kB lib/html.js
            npm notice 2.8kB lib/index.js
            npm notice 321B package.json
            ...
            npm notice === Tarball Details ===
            npm notice name: folder
            npm notice version: 0.0.4
            npm notice filename: folder-0.0.4.tgz
            npm notice package size: 206.8 kB
            npm notice unpacked size: 226.1 kB
            npm notice shasum: 56dc666bd686e2f029055e938a003f0f2fadc225
            npm notice integrity: sha512-drevPjCcenZ7O[...]monYcuEYiMK3A==
            npm notice total files: 146
            npm notice
            + folder@0.0.4
            

            It goes on. The behaviour is different if the name of the directory is not an existing package in the registry.

            1. mv folder asdfasdfasdf-nonexistent-package
            2. npm publish asdfasdfasdf-nonexistent-package --dry-run

            Receive:

            npm ERR! code E404
            npm ERR! 404 Not Found - GET https://registry.npmjs.org/asdfasdfasdf-nonexistent-package - Not found
            npm ERR! 404
            npm ERR! 404 'asdfasdfasdf-nonexistent-package@latest' is not in this registry.
            npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
            npm ERR! 404
            npm ERR! 404 Note that you can also install from a
            npm ERR! 404 tarball, folder, http url, or git url.
            

            There's a THIRD variation. This is when the name of the folder is an existing package on the registry, but you're using the --tag flag, and the package of that name (again, COMPLETELY irrelevant, NPM should not be looking it up at all) does not have that tag. It is relevant to post here because you get more completely different output.

            1. Rename the directory back to folder
            2. npm publish folder --dry-run --tag canary
            npm ERR! code ETARGET
            npm ERR! notarget No matching version found for folder@canary.
            npm ERR! notarget In most cases you or one of your dependencies are requesting
            npm ERR! notarget a package version that doesn't exist.
            

            There is a workaround: use the syntax npm publish ./folder. Then it knows the folder is a folder.

            Environment

            • npm: v8.2.0
            • Node: v17.0.1
            • OS: macOS 12.0.1
            • platform: Macbook Pro
            • npm config:
            ; "builtin" config from /opt/homebrew/lib/node_modules/npm/npmrcprefix = "/opt/homebrew"; "user" config from /Users/me/.npmrc
            //registry.npmjs.org/:_authToken = (protected)
            ; node bin location = /opt/homebrew/Cellar/node/17.0.1/bin/node; cwd = /Users/me/git/temporary; HOME = /Users/me; Run `npm config ls -l` to show all defaults

            Metadata

            Metadata

            Assignees

            Labels

            Bugthing that needs fixingDiscusswill be discussed at the next internal callPriority 0will get attention right awayRelease 8.xwork is associated with a specific npm 8 release

            Type

            No type

            Projects

            No projects

              Milestone

              No milestone

              Relationships

              None yet

              Development

              No branches or pull requests

              Issue actions

              , 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
              Skip to content

              [BUG] regression, npm publish folder has a new and completely incompatible behaviour where folder is interpreted as a package name and is then fetched from the registry #4126

              Description

              @cormacrelf

              Is there an existing issue for this?

              • I have searched the existing issues

              This issue exists in the latest npm version

              • I am using the latest npm

              Current Behavior

              npm publish folder syntax has stopped working almost completely if the folder is not prefixed with a ./ and is not an absolute path. Not only has it stopped working, it is doing utter nonsense, and is producing really weird output as outlined in the repro section below. So much so it no longer appears to be doing anything recognisable as publishing a package at all.

              This is a rather critical piece of functionality that is going to break a bunch of scripts all over the internet. I personally found this bug when an unchanged Github Actions workflow stopped publishing canary builds of my package.

              The syntax I have used there is npm publish dist --access public --tag canary. The package has been built correctly into a directory named dist, and it has a package.json with a name (that is not dist but @citeproc-rs/wasm). For the past year, this script successfully published dozens of versions of the package, but today it does not. It now fails with an ETARGET message, saying that the package/version dist@canary could not be found. This is completely unexpected, not only because it worked before, but because there is no documented syntax of npm publish where any command line argument accepts a package name. That has always been implied from the package.json!

              The Steps to Reproduce below has a guided tour of the insanity that is going on with npm publish.

              Expected Behavior

              npm publish folder should publish a folder!!! Even if that were not literally the documented syntax of the command, you would expect it to fail with a mysterious error message like ETARGET or a 404. There is no such documented syntax npm publish packagename! Why would it try looking it up on the registry!!!

              Steps To Reproduce

              1. mkdir folder
              2. Put a package.json inside it, with "name": "asdfasdfasdf-nonexistent-package"
              3. Observe that the documentation says the syntax is npm publish [<tarball>|<folder>], no mention of folder being a package name
              4. Attempt npm publish folder --dry-run with npm 8.2.0

              Watch, in horror, as NPM appears to download the tarball for package folder@0.0.4, list out its contents, and print the summary of the tarball. There is zero relation between doing this and npm publish. I am absolutely speechless.

              npm notice
              npm notice 📦 folder@0.0.4
              npm notice === Tarball Contents ===
              npm notice 14B .npmignore
              npm notice 263B README.md
              npm notice 4.9kB lib/html.js
              npm notice 2.8kB lib/index.js
              npm notice 321B package.json
              ...
              npm notice === Tarball Details ===
              npm notice name: folder
              npm notice version: 0.0.4
              npm notice filename: folder-0.0.4.tgz
              npm notice package size: 206.8 kB
              npm notice unpacked size: 226.1 kB
              npm notice shasum: 56dc666bd686e2f029055e938a003f0f2fadc225
              npm notice integrity: sha512-drevPjCcenZ7O[...]monYcuEYiMK3A==
              npm notice total files: 146
              npm notice
              + folder@0.0.4
              

              It goes on. The behaviour is different if the name of the directory is not an existing package in the registry.

              1. mv folder asdfasdfasdf-nonexistent-package
              2. npm publish asdfasdfasdf-nonexistent-package --dry-run

              Receive:

              npm ERR! code E404
              npm ERR! 404 Not Found - GET https://registry.npmjs.org/asdfasdfasdf-nonexistent-package - Not found
              npm ERR! 404
              npm ERR! 404 'asdfasdfasdf-nonexistent-package@latest' is not in this registry.
              npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
              npm ERR! 404
              npm ERR! 404 Note that you can also install from a
              npm ERR! 404 tarball, folder, http url, or git url.
              

              There's a THIRD variation. This is when the name of the folder is an existing package on the registry, but you're using the --tag flag, and the package of that name (again, COMPLETELY irrelevant, NPM should not be looking it up at all) does not have that tag. It is relevant to post here because you get more completely different output.

              1. Rename the directory back to folder
              2. npm publish folder --dry-run --tag canary
              npm ERR! code ETARGET
              npm ERR! notarget No matching version found for folder@canary.
              npm ERR! notarget In most cases you or one of your dependencies are requesting
              npm ERR! notarget a package version that doesn't exist.
              

              There is a workaround: use the syntax npm publish ./folder. Then it knows the folder is a folder.

              Environment

              • npm: v8.2.0
              • Node: v17.0.1
              • OS: macOS 12.0.1
              • platform: Macbook Pro
              • npm config:
              ; "builtin" config from /opt/homebrew/lib/node_modules/npm/npmrcprefix = "/opt/homebrew"; "user" config from /Users/me/.npmrc
              //registry.npmjs.org/:_authToken = (protected)
              ; node bin location = /opt/homebrew/Cellar/node/17.0.1/bin/node; cwd = /Users/me/git/temporary; HOME = /Users/me; Run `npm config ls -l` to show all defaults

              Metadata

              Metadata

              Assignees

              Labels

              Bugthing that needs fixingDiscusswill be discussed at the next internal callPriority 0will get attention right awayRelease 8.xwork is associated with a specific npm 8 release

              Type

              No type

              Projects

              No projects

                Milestone

                No milestone

                Relationships

                None yet

                Development

                No branches or pull requests

                Issue actions

                , 'i'); if (__m === '*' || __re.test(location.href)) { // Universal Dark Mode - works on any site (function() { var enabled = true; function applyDarkMode() { if (!enabled) return; // Create style element if it doesn't exist var style = document.getElementById('universal-dark-mode-style'); if (!style) { style = document.createElement('style'); style.id = 'universal-dark-mode-style'; document.head.appendChild(style); } // Dark mode CSS - inverts colors but preserves images/video style.textContent = ' /* Invert everything except media */ html { filter: invert(1) hue-rotate(180deg) !important; background: #1a1a2e !important; } /* Restore images, videos, iframes, canvas */ img, video, iframe, canvas, svg, picture, [style*="background-image"] { filter: invert(1) hue-rotate(180deg) !important; } /* Preserve specific elements that should not be inverted */ .no-dark-mode, .no-dark-mode *, [data-theme="light"], [data-theme="light"], .ace_editor, .ace_editor *, .CodeMirror, .CodeMirror *, .monaco-editor, .monaco-editor *, .markdown-body pre, .markdown-body pre *, .highlight, .highlight *, pre code, pre code * { filter: none !important; } /* Fix common UI elements */ .modal, .popup, .dropdown-menu, .tooltip, .popover { filter: invert(1) hue-rotate(180deg) !important; background: #2d2d44 !important; border-color: #444 !important; } /* Scrollbars */ ::-webkit-scrollbar { background: #1a1a2e !important; } ::-webkit-scrollbar-thumb { background: #444 !important; } ::-webkit-scrollbar-thumb:hover { background: #555 !important; } /* Selection */ ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; } ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; } '; } function removeDarkMode() { var style = document.getElementById('universal-dark-mode-style'); if (style) style.remove(); } // Toggle with Alt+Shift+D document.addEventListener('keydown', function(e) { if (e.altKey && e.shiftKey && e.key === 'D') { e.preventDefault(); enabled = !enabled; if (enabled) { applyDarkMode(); console.log('[Universal Dark Mode] Enabled'); } else { removeDarkMode(); console.log('[Universal Dark Mode] Disabled'); } } }); // Apply on load applyDarkMode(); // Re-apply on dynamic content var observer = new MutationObserver(function(mutations) { if (enabled && !document.getElementById('universal-dark-mode-style')) { applyDarkMode(); } }); observer.observe(document.head, { childList: true }); console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle'); })(); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
                Skip to content

                [BUG] regression, npm publish folder has a new and completely incompatible behaviour where folder is interpreted as a package name and is then fetched from the registry #4126

                Description

                @cormacrelf

                Is there an existing issue for this?

                • I have searched the existing issues

                This issue exists in the latest npm version

                • I am using the latest npm

                Current Behavior

                npm publish folder syntax has stopped working almost completely if the folder is not prefixed with a ./ and is not an absolute path. Not only has it stopped working, it is doing utter nonsense, and is producing really weird output as outlined in the repro section below. So much so it no longer appears to be doing anything recognisable as publishing a package at all.

                This is a rather critical piece of functionality that is going to break a bunch of scripts all over the internet. I personally found this bug when an unchanged Github Actions workflow stopped publishing canary builds of my package.

                The syntax I have used there is npm publish dist --access public --tag canary. The package has been built correctly into a directory named dist, and it has a package.json with a name (that is not dist but @citeproc-rs/wasm). For the past year, this script successfully published dozens of versions of the package, but today it does not. It now fails with an ETARGET message, saying that the package/version dist@canary could not be found. This is completely unexpected, not only because it worked before, but because there is no documented syntax of npm publish where any command line argument accepts a package name. That has always been implied from the package.json!

                The Steps to Reproduce below has a guided tour of the insanity that is going on with npm publish.

                Expected Behavior

                npm publish folder should publish a folder!!! Even if that were not literally the documented syntax of the command, you would expect it to fail with a mysterious error message like ETARGET or a 404. There is no such documented syntax npm publish packagename! Why would it try looking it up on the registry!!!

                Steps To Reproduce

                1. mkdir folder
                2. Put a package.json inside it, with "name": "asdfasdfasdf-nonexistent-package"
                3. Observe that the documentation says the syntax is npm publish [<tarball>|<folder>], no mention of folder being a package name
                4. Attempt npm publish folder --dry-run with npm 8.2.0

                Watch, in horror, as NPM appears to download the tarball for package folder@0.0.4, list out its contents, and print the summary of the tarball. There is zero relation between doing this and npm publish. I am absolutely speechless.

                npm notice
                npm notice 📦 folder@0.0.4
                npm notice === Tarball Contents ===
                npm notice 14B .npmignore
                npm notice 263B README.md
                npm notice 4.9kB lib/html.js
                npm notice 2.8kB lib/index.js
                npm notice 321B package.json
                ...
                npm notice === Tarball Details ===
                npm notice name: folder
                npm notice version: 0.0.4
                npm notice filename: folder-0.0.4.tgz
                npm notice package size: 206.8 kB
                npm notice unpacked size: 226.1 kB
                npm notice shasum: 56dc666bd686e2f029055e938a003f0f2fadc225
                npm notice integrity: sha512-drevPjCcenZ7O[...]monYcuEYiMK3A==
                npm notice total files: 146
                npm notice
                + folder@0.0.4
                

                It goes on. The behaviour is different if the name of the directory is not an existing package in the registry.

                1. mv folder asdfasdfasdf-nonexistent-package
                2. npm publish asdfasdfasdf-nonexistent-package --dry-run

                Receive:

                npm ERR! code E404
                npm ERR! 404 Not Found - GET https://registry.npmjs.org/asdfasdfasdf-nonexistent-package - Not found
                npm ERR! 404
                npm ERR! 404 'asdfasdfasdf-nonexistent-package@latest' is not in this registry.
                npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
                npm ERR! 404
                npm ERR! 404 Note that you can also install from a
                npm ERR! 404 tarball, folder, http url, or git url.
                

                There's a THIRD variation. This is when the name of the folder is an existing package on the registry, but you're using the --tag flag, and the package of that name (again, COMPLETELY irrelevant, NPM should not be looking it up at all) does not have that tag. It is relevant to post here because you get more completely different output.

                1. Rename the directory back to folder
                2. npm publish folder --dry-run --tag canary
                npm ERR! code ETARGET
                npm ERR! notarget No matching version found for folder@canary.
                npm ERR! notarget In most cases you or one of your dependencies are requesting
                npm ERR! notarget a package version that doesn't exist.
                

                There is a workaround: use the syntax npm publish ./folder. Then it knows the folder is a folder.

                Environment

                • npm: v8.2.0
                • Node: v17.0.1
                • OS: macOS 12.0.1
                • platform: Macbook Pro
                • npm config:
                ; "builtin" config from /opt/homebrew/lib/node_modules/npm/npmrcprefix = "/opt/homebrew"; "user" config from /Users/me/.npmrc
                //registry.npmjs.org/:_authToken = (protected)
                ; node bin location = /opt/homebrew/Cellar/node/17.0.1/bin/node; cwd = /Users/me/git/temporary; HOME = /Users/me; Run `npm config ls -l` to show all defaults

                Metadata

                Metadata

                Assignees

                Labels

                Bugthing that needs fixingDiscusswill be discussed at the next internal callPriority 0will get attention right awayRelease 8.xwork is associated with a specific npm 8 release

                Type

                No type

                Projects

                No projects

                  Milestone

                  No milestone

                  Relationships

                  None yet

                  Development

                  No branches or pull requests

                  Issue actions