Today we're excited to bring you some highly anticipated additions to our Audit and Cloud products: monorepos, workspaces, and npm v1 lockfile support.
Monorepo Support
Sandworm Cloud now scans repos for directories that contain a
package.jsonmanifest and runs a full audit on every individual app detected.
Monorepos, short for "monolithic repositories," refer to a development approach where multiple projects, components, or applications are housed within a single repository. While this approach might seem counterintuitive to the traditional practice of maintaining separate repositories for each project, it has gained significant traction in recent years, particularly among larger tech companies and open-source projects. The case for monorepos rests on several key benefits:
Simplified Collaboration and Code Sharing: With all projects in one place, developers can easily share code, dependencies, and documentation. This fosters collaboration and reduces redundancy, as teams can collaborate more effectively across projects.
Shared Dependencies: In a monorepo, shared dependencies (libraries, packages, etc.) are managed more efficiently. This reduces version conflicts and eases the burden of maintaining different versions across multiple repositories.
Streamlined Maintenance: Developers can make changes across multiple projects or components in a unified manner. This simplifies tasks like updating a shared component or applying security patches, as changes can be applied consistently.
Easier Refactoring: Refactoring becomes more manageable in a monorepo since the entire codebase is accessible. If a change in one component requires updates in others, those changes can be made in a coordinated fashion.
Improved Testing and CI/CD: Running tests and continuous integration/continuous deployment (CI/CD) pipelines across all projects becomes easier in a monorepo. This ensures consistency in testing and deployment practices.
Workspace Support
Sandworm Audit v1.46.0 can now detect if the input path points to a package inside a workspace, and uses the workspace lockfile instead of a local one. Npm, Yarn, as well as Pnpm workspaces are supported.
Sandworm Cloud can also properly identify and audit workspace-based repos.
Workspaces are a feature of the npm, Yarn, and pnpm package managers that allow you to manage multiple packages from your local file system from within a singular top-level, root package. They can be used to organize and manage large codebases, as well as to facilitate collaboration between developers.
Workspaces and monorepos are closely related. Workspaces can be used to create monorepos, and monorepos can be used to take advantage of workspace features.
Here are some of the benefits of using workspaces:
Simplified dependency management: Workspaces and monorepos make it easier to manage dependencies between packages. This can help to reduce errors and improve the stability of your codebase.
Improved build performance: Workspaces can improve the performance of your builds by enabling npm to hoist dependencies that are shared between packages. This means that dependencies are only installed once, even if they are used by multiple packages.
Reduced disk space usage: Workspaces can reduce the disk space usage of your project by using symlinks instead of hard links to point to the dependencies of your packages. This can be a significant savings for large projects with many dependencies.
Npm Lockfile V1 Support
Sandworm Cloud and Sandworm Audit now support all versions of npm lockfiles.
The npm lockfile v1 was introduced in npm v5. It is a JSON file that records the exact versions of all the dependencies that were installed when you ran npm install. This ensures that your project will always have the same dependencies, even if you install them on a different machine or if the dependencies are updated in the npm registry.
The npm lockfile v1 has a number of limitations, including:
It only records the versions of dependencies, not their SHA checksums. This means that if a dependency is updated with a new version that has the same semantic version number, the lockfile will not be updated.
It does not record the location of dependencies in the file system. This means that if you move your project to a different machine, the lockfile will not be able to find the dependencies.
The npm lockfile v2 was introduced in npm v7. It is a JSON file that records the exact versions and SHA checksums of all the dependencies that were installed when you ran npm install. It also records the location of dependencies in the file system. This ensures that your project will always have the same dependencies, even if you install them on a different machine or if the dependencies are updated in the npm registry.
The npm lockfile v2 is a significant improvement over the npm lockfile v1. It is more reliable and it provides more information about the dependencies of your project. However, many older projects have never migrated away from v1 - we've seen many such old lockfiles in the repos secured with Sandworm Cloud.
Keep your JavaScript projects & dependencies safe with Sandworm 👇
Sandworm Audit is the open-source
npm auditthat doesn’t suck: it checks for multiple types of issues, like vulnerabilities or license compliance, it outputs SVG charts and CSVs, it can mark issues as resolved, and you can also run it in your CI to enforce security rules. Check the docs andnpx @sandworm/audit@latestin your JavaScript app’s root to try it out 🪱.