Closed IanVS closed 1 year ago
Hm, based on the CI failures we might need to also require react to be a peer dependency like we do in SB 7. :-/
Looks good. :)
Turns out that rollup does not respect NODE_PATH, so we need to do a bit of resolution hackery to get it to resolve react relative to the example, and not from within builder-vite's node_modules. Normal projects will not need to worry about this, it's just due to our non-standard multi-project example structure.
Dependency issues detected. If you merge this pull request, you will not be alerted to the instances of these issues again.
Install scripts are run when the package is installed. The majority of malware in npm is hidden in install scripts.
Packages should not be running non-essential scripts during install and there are often solutions to problems people solve with install scripts that can be run at publish time instead.
Package | Script field | Source |
---|---|---|
@swc/core@1.3.34 (upgraded) | postinstall |
examples/react-18/package.json via @vitejs/plugin-react-swc@3.1.0, packages/builder-vite/package.json via @vitejs/plugin-react-swc@3.1.0 |
A new npm collaborator published a version of the package for the first time. New collaborators are usually benign additions to a project, but do indicate a change to the security surface area of a package.
Scrutinize new collaborator additions to packages because they now have the ability to publish code into your dependency tree. Packages should avoid frequent or unnecessary additions or changes to publishing rights.
Issue | Status |
---|---|
Install scripts | ⚠️ 1 issue |
Native code | ✅ 0 issues |
Bin script confusion | ✅ 0 issues |
Bin script shell injection | ✅ 0 issues |
Shell access | ✅ 0 issues |
Uses eval | ✅ 0 issues |
Unresolved require | ✅ 0 issues |
Invalid package.json | ✅ 0 issues |
HTTP dependency | ✅ 0 issues |
Git dependency | ✅ 0 issues |
GitHub dependency | ✅ 0 issues |
New author | ⚠️ 1 issue |
Potential typo squat | ✅ 0 issues |
Known Malware | ✅ 0 issues |
Telemetry | ✅ 0 issues |
Protestware/Troll package | ✅ 0 issues |
AI detected malware | ✅ 0 issues |
To ignore an alert, reply with a comment starting with @SocketSecurity ignore
followed by a space separated list of package-name@version
specifiers. e.g. @SocketSecurity ignore foo@1.0.0 bar@2.4.2
@SocketSecurity ignore @swc/core@1.3.34
@SocketSecurity ignore regexpu-core@5.3.0
Powered by socket.dev
@joshwooding I'm having trouble with Windows here. Any chance you can give this a shot?
Hi @IanVS
from issue 21023
CI passed when enabled previewMdx2
:
so maybe this is mdx1-csf
transform issue: 👀
Yes, mdx1 requires us to inject an import into the code, and the yarn portal we are using for the examples doesn't seem to be working very well, because imports in builder-vite are not resolving back to the example's node_modules without some help. It's working fine on posix systems, but not windows. I'm tempted to merge anyway and hope that Josh can get our CI green later. It's only an issue in our examples I believe.
fixes https://github.com/storybookjs/builder-vite/issues/557
I found that mdx was not working correctly here, and @valentinpalkovic realized my fallback in Storybook 7 wasn't either (https://github.com/storybookjs/storybook/pull/20823). It was because we used to inject the mdx compiler into the source code that we get back from the
@storybook/mdx1-csf
compiler, but we lost that in https://github.com/storybookjs/builder-vite/pull/548/files#diff-f2dfc4dfa9074d77a728a88e6629a1d66be8a0765cab8562526cd00fbae910e5L6. This re-introduces it, with a bit better of a guarantee that the correct version is going to be loaded, by starting from inside@storybook/mdx1-csf
.I've also pinned mdx1-csf here, in case the import is moved from the loader to the compiler, as @shilman has suggested doing. We'll need to adjust this if that happens.