-
Notifications
You must be signed in to change notification settings - Fork 59
feat: add support for deno #262
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
Conversation
Adds support for Deno monorepos to the `get-packages` tool. This is achieved by: - Adding a `DenoTool` to `@manypkg/tools` that can read and parse `deno.json` and `deno.jsonc` files. - Using the `jsonc-parser` library to handle JSON with comments. - Updating `@manypkg/find-root` to include the new `DenoTool` in the default tool detection. - Adding a test case to verify the new functionality.
Adds support for Deno monorepos to the `get-packages` tool. This is achieved by: - Adding a `DenoTool` to `@manypkg/tools` that can read and parse `deno.json` and `deno.jsonc` files. - Adding a new `expandDenoPackageGlobs` function to correctly find Deno packages within a monorepo. - Using the `jsonc-parser` library to handle JSON with comments. - Updating `@manypkg/find-root` to include the new `DenoTool` in the default tool detection. - Adding a test case to verify the new functionality.
|
486485c
to
d3e7c47
Compare
This commit expands the tests for Deno configuration files (`deno.json` and `deno.jsonc`) to ensure they can handle complex scenarios. A new test fixture `complex-deno` has been added, which includes a `deno.jsonc` file with: - Comments - Complex import aliases (jsr:, npm:, https:) - Various other Deno-specific properties The test case verifies that the `getPackages` function correctly parses this complex configuration and that the returned data is valid.
This commit expands the tests for Deno configuration files (`deno.json` and `deno.jsonc`) to ensure they can handle complex scenarios, including multi-package workspaces. A new test fixture `complex-deno` has been added, which includes a `deno.jsonc` file with: - Comments - Complex import aliases (jsr:, npm:, https:) - Various other Deno-specific properties The test fixture has been refactored to represent a multi-package workspace, with the complex configuration distributed among the sub-packages. The test case verifies that the `getPackages` function correctly parses this complex configuration and that the returned data is valid for all packages in the workspace.
The DenoTool and expandDenoGlobs files contained redundant logic for finding `deno.json` and `deno.jsonc` files. This change abstracts this logic into new `findDenoConfig` and `findDenoConfigSync` helper functions in `utils.ts`. The following files were updated to use the new helper functions: - `packages/tools/src/DenoTool.ts` - `packages/tools/src/expandDenoGlobs.ts` This refactoring simplifies the code and makes it more maintainable without changing the functionality. All tests pass after the changes.
This change adds support for deno to the manypkg cli. It updates the `run` command to work with deno projects. It also adds the ability to parse dependencies from the `imports` field in `deno.json` and `deno.jsonc` files.
This commit introduces support for Deno workspaces in the manypkg command-line tool. The key changes include: - Refactoring the `run` command logic to be tool-agnostic and support `deno task`. - Enhancing the `writePackage` utility to correctly detect and write changes to `deno.json` and `deno.jsonc` files. - Updating the `install` command to be a no-op for Deno, with an explanatory message, as Deno's dependency management differs from Node.js package managers. - Adding tests to verify the new Deno functionality for the `run` and `writePackage` commands.
This commit introduces support for Deno workspaces in the `manypkg check` command. It makes the following checks Deno-aware: - EXTERNAL_MISMATCH - INTERNAL_MISMATCH - INVALID_PACKAGE_NAME - UNSORTED_DEPENDENCIES To achieve this, the codebase was refactored to make the checks "tool-aware". The `Package` object now includes a `tool` property, so that each check can inspect the tool type and apply the correct logic for either Deno or Node.js-based projects. All `Tool` implementations (`DenoTool`, `YarnTool`, etc.) have been updated to attach the `tool` object to the packages they produce.
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Moves the DenoJSON type from the tools package to a separate file and exports it from the package's entry point. This allows other packages to import the type using a package-based import instead of a relative path. This change also adds the @manypkg/tools package as a devDependency to the @manypkg/cli package and updates the import statement in the corresponding test file.
This commit updates all remaining cross-package relative imports for the DenoJSON type to use the package-based import from @manypkg/tools. This change is a follow-up to the previous refactoring and ensures that all cross-package references for this type are consistent with monorepo best practices.
This commit refactors the core types to use a discriminated union for `PackageJSON` and `DenoJSON` in the `Package` interface. A type guard function `isDenoPackage` has been introduced to safely narrow the type of `packageJson` based on the `tool.type` property. This eliminates the need for unsafe type assertions like `as DenoJSON` throughout the codebase. All relevant files have been updated to use the new type guard, improving type safety and code readability.
This commit fixes all the TypeScript errors that were reported by `tsc`. The main changes are: - Moved the `isDenoPackage` and `isNodePackage` type guards to `packages/tools/src/Tool.ts` to break a circular dependency. - Updated the test helper `getFakeWS` to return a more specific type to help with type inference in test files. - Used the `isNodePackage` type guard in all the places where Node.js specific properties were accessed on the `packageJson` object.
All alerts resolved. Learn more about Socket for GitHub. This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored. |
1b7cda0
to
7d79e88
Compare
6f88bdc
to
10d5908
Compare
This commit introduces the necessary changes to make the `manypkg fix` command fully functional for Deno workspaces. The key changes include: - **`writePackage` for Deno:** The `writePackage` utility in the CLI is now tool-aware. It can detect Deno packages and correctly write changes to `deno.json` or `deno.jsonc` files. This unblocks the `fix` command. - **Deno-aware `install`:** The `install` utility is now Deno-aware and functions as a no-op for Deno projects, preventing errors during the `fix` workflow. - **Robust Dependency Fixing:** The fixing logic for `EXTERNAL_MISMATCH` and `INTERNAL_MISMATCH` checks has been refactored. It no longer makes unsafe assumptions about the dependency protocol and correctly reconstructs the import specifier. - **Improved Dependency Parsing:** The regular expression for parsing Deno dependencies has been improved to correctly handle complex URLs from CDNs, especially those with query parameters. - **Enhanced Test Coverage:** A new end-to-end test has been added to verify that `manypkg fix` works correctly on a Deno project. A unit test for parsing complex dependency URLs has also been added.
This commit refactors the `Package` type in `@manypkg/tools` to be a generic type, `Package<T>`, where `T` can be either `PackageJSON` or `DenoJSON`. This change allows for more specific and type-safe handling of Node.js and Deno packages throughout the codebase. The main changes are: - The `Package` interface in `packages/tools/src/Tool.ts` is now generic. - The `isDenoPackage` and `isNodePackage` type guards have been updated to work with the new generic type. - All package creation sites and type annotations have been updated to use the new generic `Package<T>` type. This refactoring eliminates the need for ugly type casts and assertions like `as any` and `& { packageJson: PackageJSON }`, which were previously necessary due to the union type on the `packageJson` property. The codebase is now more type-safe and easier to maintain.
@fry69 to be fair, I just don't have a lot of bandwidth to handle a PR like this. I can try to take a look in here to answer you or if you ping me (feel free to do so from time to time if I don't respond within a couple of days). I don't promise anything though. Could you just tell what is the exact scope of the Deno support you'd like to see in manypkg? What doesn't work today at all and what you would like to get fixed? I mean, I get that |
My motivation is to get some kind of With some distance I now see that the bottom up approach and trying to get I will not further pursue this route and close this pull request. Thank you for your time. |
FWIW, to support Deno in Changesets, it would probably make sense to add Deno support to |
Addresses #239
This is a first attempt for supporting Deno and
deno.json
/deno.jsonc
files. The main motivation is to add support for Deno inchangesets
.Disclaimer: This code was written by Google Jules, but reviewed by me. At first glance it looks promising. Please comment.
Jules wrote the pull request message below:
Description
This pull request adds comprehensive support for Deno workspaces to
manypkg
. The primary motivation is to enable Deno support in downstream tools likechangesets
, which rely onmanypkg
's CLI for workspace analysis.What this PR does:
DenoTool
: Implements a new tool for detecting and parsing Deno workspaces based on deno.json or deno.jsonc files.manypkg
fix command now works correctly for Deno projects.writePackage
utility is now tool-aware and correctly writes changes todeno.json
anddeno.jsonc
files.EXTERNAL_MISMATCH
andINTERNAL_MISMATCH
checks has been refactored to be protocol-agnostic and correctly reconstruct import specifiers.deno
task to execute scripts in Deno projects.manypkg
fix correctly modifies a deno.jsonc file on the filesystem.