chore(bit): update deps that have vulnerabilities #8804
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The capsule base-dir is normally a `sha1` of the workspace/scope dir, which is 40 chars long. Problem is that Windows is not happy with long paths. This PR uses a shorter hash. The number 9 is pretty random, it's what we use for short-hash of snaps. We're aware of an extremely low risk of collision. Keep in mind that in most cases you won't have more than 10 capsules in the machine, so it's fine.
…ing easier (#8828) With this flag, no need to push to the remote in order to investigate the `Version` object changes.
currently, if there are local changes in the component.json (generated by `bit config eject-conf`), then `bit checkout reset` doesn't reset them. It leaves the file as is. This PR refactors the way how this component.json file is saved to reuse the infrastructure we had for package.json (with indent and EOL taken into account). With this, it was easier to change the component-written command to make sure this file is written if it was there before.
…d by "bit remove" (#8829)
…onents (#8830) Otherwise, the components that depend on these removed aspects are trying to load them, find out they don't exists, then trying to import them and throw an error "unable to import". Because these removed aspects are new, there is no easy way to fix this. It's impossible to install them as packages. This PR blocks it unless `--force` flag was used.
…plate name (#8831) Otherwise, the code might have a class that extends itself. For example, `bit create node-env node-env` produces `class NodeEnv extends NodeEnv`. Or `bit create react-env envs/react-env --aspect teambit.react/react-env` produces `class ReactEnv extends ReactEnv`.
remove the duplicate "error".
This command is useful when you got a messy merge state that from one hand you don't want to loose the changes, but on the other hand, you want to keep your lane without those changes. This command does the following: 1. create a new lane with the current merge state. including all the filesystem changes. (in practice, it leaves the fs intact). 2. reset the current lane to the state before the merge, so then once done with the new lane, you can switch to the current lane and it'll be clean.
…en on a lane (#8836) We used to throw an error suggesting the user to import the components individually. The reason was that when you're on a lane, you probably want to import components from the lane. not main. That's why when the wildcard matches both, lane and main, only the lane are imported. However, if only components from main are matched, it's not very clear whether you really want to import from lane, or your wildcard syntax didn't bring the results you thought it would. With this PR we assume that in this case you do want to import from main so we let you do that.
…e of objects rather than trying to fetch them (#8839) This will be actually used once remotes are updated and support the new GraphQL query.
Once deployed on the remote scopes, it can help a client in negotiating with the server and adjusting API compatibility.
When the `bit scope-rename` (or `bit rename`) suppose to change multiple values in the workspace.jsonc, it was changing only the first one.
…t from specific files (#8806)
…ge (#8844) Similar to `bit deprecate --range`, this new flag allows deleting specific tags. For example `bit delete my-comp --range 0.0.1`. It marks 0.0.1 only as deleted. This is supported in `bit log`. It's also shown in the `bit import` and `bit show` output. For example, when running `bit show my-comp@0.0.2` the "removed" is false. However, `bit show my-comp@0.0.1` shows it as true. It also shows the range.
Until now, `.gitignore` files were always ignored by default and never tracked by Bit. ## Proposed Changes - track `.gitignore` files. This way, when multiple users import the same component and using different git repos, they could use the same .gitignore file. - in case `.gitignore` is found in the component root-dir, Bit reads it and uses it to untrack component files. - in case `.bitignore` is found in the component root-dir in addition to `.gitignore`, the `.bitignore` takes precedence and is used to untrack component files. (still, `.gitignore` itself is tracked). This way, it's possible to have different patterns/rules for bit and git. - until now, bit was searching for the `.gitignore` of the workspace-root, now only in the workspace-root, but also upwards until it finds it. This is unintuitive and can cause confusion. It was changed to use only the one in the workspace root.
This is done via `bit ws-config` for awhile now
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Vulnerability Report
Summary
Total vulnerabilities: 72
Detailed Report
CRITICAL Severity Vulnerabilities
HIGH Severity Vulnerabilities
Sec-Websocket-Protocolheader usedMEDIUM Severity Vulnerabilities
LOW Severity Vulnerabilities