Skip to content
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

[pull] latest from npm:latest #11

Open
wants to merge 1,657 commits into
base: latest
Choose a base branch
from
Open

[pull] latest from npm:latest #11

wants to merge 1,657 commits into from

Conversation

pull[bot]
Copy link

@pull pull bot commented Apr 15, 2022

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

wraithgar and others added 30 commits December 16, 2024 10:12
When searching for multiple terms in npm, the highlighting code has a
bug where it duplicates the output any time there are matching terms.
This fixes the highlighting code.


Before:
![output of "npm search gar promisify" showing the name being
duplicated](https://github.com/user-attachments/assets/2f34ece7-7563-4db1-a540-3bb661a4c3e0)



After:
![output of "node . search gar promisify" showing the name being
displayed
correctly](https://github.com/user-attachments/assets/ba31fcd9-caf3-4a08-8bbb-7f5242f0098b)
Certain project dependency trees may result in an SBOM with duplicate
entries. This fix ensures that each unique dependency (identified by the
combination of package name and version) only appears in the SBOM once.
Applies to both SPDX and CycloneDX SBOM formats.

Specific to the CycloneDX format, this change also removes the
`cdx:npm:package:path` property from the `component` entries in the
generated SBOM. Since the same package may be present at multiple paths
within the project and we're now de-duplicating those packages, it no
longer makes sense to include this in the SBOM. This does not impact the
SPDX format as there is no equivalent property.

Fixes: #6967

Signed-off-by: Brian DeHamer <[email protected]>
Noticed some of the resources pointed to external sites not controlled
by npm or github and wanted to clean them up so they can't be squatted
on.
Setting `tag` in `publishConfig` constitutes a "non default" scenario.
documentation of `ls` command specifies that `depth` flag if not set
defaults to `1` but as per code it uses 0 as default value.
https://github.com/npm/cli/blob/dc31c1bdc6658ab69554adcf2988ee99a615c409/lib/commands/ls.js#L113-L116

fixes: #7979
This PR fixes small typos in the documentation for "configuring
npm/package-json"
…8054)

Merges #7993 /
#7994 /
#7995

- [x] adds ability to --force publish without latest check
- [x] adds ability to --force publish of prerelease without tag
- [x] consider equality in publish dist tag check error message
Update the copy for "requirements" to specify that it is the Node.js
support lifecycle that is key, not a specific version.

Also removed the badges from the readme. Most of that info is already on
the page as parsed by GitHub.
#8054 broke the smoke test because were
publishing the current version in a test
Im a big proponent of scripts working the same way in ci as they would
locally. and that we should be able to run anything the ci does locally.
The publish script is used to publish npm and ws packages, but also
within a series of smoke tests. Making the flags clear it's either one
of the two paths was my goal.
This removes the `publish.sh --smoke-publish` like from the current
`smoke-publish-test.sh` (renaming it to `smoke-test.sh`) and runs both
operations as seperete jobs within the `ci.yml` (on pr) and
`ci-release.yml` (on merge) workflow.

Why? To avoid changed files / git dirty issues from one operation to the
next.

With this PR we should have the same checks that merge has, on pr as
well, preventing scenarios where a PR breaks a `smoke test` or `publish
--smoke-publish` test. The only difference between merge / pr is that
merge has more tested node versions, if PRs start to pass but fail in
these version lets add the full matrix.

```sh
npm i npm@latest -g && node scripts/git-dirty.js && node scripts/resetdeps.js && ./scripts/smoke-tests.sh
```

```sh
npm i npm@latest -g && node scripts/git-dirty.js && node scripts/resetdeps.js && node ./scripts/publish.js --pack-destination=${pwd} --smoke-publish=true
```
It is not a valid cli flag, single-hyphen flags should all be single-character.  Eventually `-ws` will need to go away so will at least stop suggesting it now.
Single hyphen cli flags traditionally are single-character only, so they
can be combined. npm already supports combining single-hyphen flags
together, so it eventually needs stop supporting multi-character ones.

Also re-added -ws to undocumented shorthands, it was accidentally
removed from the main config and not re-added to the internal one.

Finally, warnings on a few env configs that npm tosses around were
suppressed for now.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.