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

refactor(ghjk.ts): replace secureConfig with hack.ts #87

Merged
merged 6 commits into from
Jun 4, 2024

Conversation

Yohe-Am
Copy link
Contributor

@Yohe-Am Yohe-Am commented May 27, 2024

Describe your change

  • Get rid of secureConfig.
  • Hard panic if hack.ts functions are called from more than one module.

Motivation and context

The old abstraction is no longer adequate and it's not a great looking API for a half-measure.

Migration notes

  • The secureConfig object is no more. Users are expected to now use the config function exported from hack.ts for out of band configuration.
  • The different functions used for building ghjkfiles are now exported from hack.ts instead of mod.ts.
  • mod.ts now exports a file function that can be used to securely write your ghjkfile. file returns the familiar builder functions along with the sophon.
  • The one export expected from ghjk.ts files has been renamed from ghjk to sophon.
    • The name is WIP and nabbed from Three Body Problem (desc here, beware spoilers). It's a small object that bridges two words, in this case the frontend and backend.
    • The old name, ghjk, is now expected to be used as the return value of the file function. Look at the kitchen sink example for a sample.
    • Better names are appreciated, something not too generic.

Checklist

  • The change come with new or modified tests
  • Hard-to-understand functions have explanatory comments
  • End-user documentation is updated to reflect the change

Summary by CodeRabbit

  • New Features

    • Introduced sophon as the new tool name, replacing ghjk.
    • Added a new exclusion pattern for markdown files in the fmt section.
    • Implemented a new hack.ts module for managing global state and security.
  • Improvements

    • Updated environment and task configurations for better clarity and functionality.
    • Enhanced the genTsGhjkFile function for streamlined handling of configurations and tasks.
  • Bug Fixes

    • Fixed issues with dependency resolution by renaming allowedPortDeps to allowedBuildDeps.
  • Documentation

    • Updated the README.md to reflect new configurations and usage instructions for sophon.
  • Refactor

    • Refactored import paths and export declarations to align with the new sophon module.
    • Adjusted various configurations and function calls to improve code maintainability and security.

@Yohe-Am Yohe-Am changed the title refactor(ghjk.ts): replace secureConfig with hack.ts refactor(ghjk.ts): replace secureConfig with hack.ts May 27, 2024
Copy link

coderabbitai bot commented May 27, 2024

Important

Review skipped

Auto reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

The updates primarily involve renaming ghjk to sophon, modifying configuration settings, and updating import paths across various files. The changes include adjustments to environment variables, task definitions, and dependency handling, along with the introduction of new configurations and refactoring for better security and functionality.

Changes

File(s) Change Summary
.ghjk/lock.json Removed blocks related to specific identifiers, modified configurations under "tasks" and "test" sections, updated "envs" and "tasks" configurations, and adjusted "provides" entries.
.github/workflows/tests.yml Updated directory path and replaced command protoc --version with ghjk x hey.
README.md Renamed ghjk to sophon, updated import paths, altered task definitions, and introduced a new hack.ts module.
check.ts Added exclusion for the ".git" directory when expanding glob patterns.
deno.jsonc Added a new exclusion pattern *.md under the fmt section.
examples/envs/ghjk.ts Introduced configurations for different environments, setting default environment variables, and defining tasks.
examples/kitchen/ghjk.ts Added configuration for defining environments, tasks, and installations.
examples/tasks/ghjk.ts Updated to export sophon instead of ghjk, and modified task installation and environment variable usage.
files/deno/worker.ts Updated function call to use sophon module instead of ghjk.
files/mod.ts Renamed allowedPortDeps to allowedBuildDeps, adjusted types, and updated related methods and properties.
ghjk.ts Changed exported entity, updated imports, and modified configuration settings for environment and runtime behavior.
hack.ts Provided functionality for securing a TypeScript ghjkfile.
modules/ports/mod.ts Renamed allowedDeps to allowedBuildDeps within the set object.
modules/ports/sync.ts Updated references from set.allowedDeps to set.allowedBuildDeps.
modules/ports/types.ts Renamed allowedDeps to allowedBuildDeps within the installSet object.
modules/tasks/deno.ts Updated function call to use sophon module instead of ghjk.
tests/envHooks.ts Modified ePoint assignment and updated export/import statements for sophon.
tests/envs.ts Updated type import and adjusted the structure of secureConfig and genTsGhjkFile.
tests/ports.ts Renamed DenofileSecureConfig to FileArgs and updated related properties and methods.
tests/reloadHooks.ts Introduced a conditional statement for ePoint and refactored envDefs structure.
tests/tasks.ts Renamed envVars to vars, changed allowedPortDeps to allowedBuildDeps, and updated exports/imports.
tests/utils.ts Refactored genTsGhjkFile function, updated JSON serialization, and adjusted structure for task processing.
utils/mod.ts Added a new mapObject function within the exported constant $.

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share
Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@Yohe-Am Yohe-Am marked this pull request as ready for review May 30, 2024 03:00
@Yohe-Am Yohe-Am requested review from zifeo, Natoandro and destifo May 30, 2024 03:00
@Yohe-Am
Copy link
Contributor Author

Yohe-Am commented May 30, 2024

@coderabbitai review

Copy link

coderabbitai bot commented May 30, 2024

Actions Performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 16

Outside diff range and nitpick comments (34)
ghjk.ts (1)

9-9: The use of install function without specific parameters in a production file might not be ideal unless it's for demonstration or testing purposes.

Consider removing or commenting out these lines if they are not intended for production use.

Also applies to: 20-20

examples/tasks/ghjk.ts (1)

Line range hint 22-22: Replace unnecessary template literals with simple strings to improve performance and readability.

-  $`echo Hello ${name}!`;
+  echo("Hello " + name + "!");
-  $`echo enter`;
+  echo("enter");
-  $`echo exit`;
+  echo("exit");
-  $`echo remark > marker`;
+  echo("remark > marker");

Also applies to: 28-28, 33-33, 42-42

modules/tasks/deno.ts (1)

Line range hint 117-117: Replace != with !== for strict inequality checks to ensure type safety.

-  if (resp.ty != "exec") {
+  if (resp.ty !== "exec") {
tests/tasks.ts (2)

38-38: Consider simplifying the object structure.

The vars object could be simplified by directly assigning the values without the extra braces, improving readability.


153-156: Clarify the purpose of secureConf.

The secureConf object is used here without clear documentation. Consider adding comments to explain its purpose and how it should be used.

tests/envs.ts (1)

20-20: Clarify the use of secureConfig.

The secureConfig property is used here without clear documentation. Consider adding comments to explain its purpose and how it should be used.

tests/reloadHooks.ts (1)

207-217: Clarify the configuration of environments.

The configuration of environments in secureConf is complex and could benefit from additional comments to improve maintainability.

tests/ports.ts (1)

12-12: Document the secureConf property.

The secureConf property is used here without clear documentation. Consider adding comments to explain its purpose and how it should be used.

files/deno/worker.ts (1)

Line range hint 22-22: Use strict equality checks.

Replace loose equality checks with strict equality to avoid potential bugs.

- if (req.ty == "serialize") {
+ if (req.ty === "serialize") {

Also applies to: 94-94

modules/ports/mod.ts (4)

Line range hint 74-84: Refactor the handling of allowedBuildDeps to improve clarity and maintainability.

- const allowedBuildDeps = Object.fromEntries(
-   Object.entries(allowedDepSetHashed).map((
-     [key, hash],
-   ) => [
-     key,
-     unwrapParseCurry(validators.allowedPortDep.safeParse(bb[hash])),
-   ]),
- );
+ const allowedBuildDeps = Object.fromEntries(Object.entries(allowedDepSetHashed).map(
+   ([key, hash]) => [key, unwrapParseCurry(validators.allowedPortDep.safeParse(bb[hash]))]
+ ));

Line range hint 121-129: Convert function expressions to arrow functions for consistency and modern JavaScript practices.

- .action(function () {
+ .action(() => {
- .action(async function () {
+ .action(async () => {
- .action(function () {
+ .action(() => {

Also applies to: 135-137, 143-145


Line range hint 155-155: Use strict equality check (!==) instead of loose equality (!=).

- if (entry.version != "0") {
+ if (entry.version !== "0") {

Line range hint 156-156: Avoid using template literals when not necessary.

- throw new Error(`unexepected version tag deserializing lockEntry`);
+ throw new Error("unexepected version tag deserializing lockEntry");
tests/utils.ts (2)

Line range hint 22-22: Use template literals consistently for string operations.

- const dockerPlatform = "--platform=" + testTargetPlatform.replace("x86_64", "amd64").replace("aarch64", "arm64");
+ const dockerPlatform = `--platform=${testTargetPlatform.replace("x86_64", "amd64").replace("aarch64", "arm64")}`;

Also applies to: 41-41


Line range hint 79-80: Optimize array operations by using .flatMap() instead of .map().flat().

- ...Object.entries(env).map(([key, val]) => ["-e", `${key}=${val}`]).flat(),
+ ...Object.entries(env).flatMap(([key, val]) => ["-e", `${key}=${val}`]),
utils/mod.ts (7)

Line range hint 299-299: Use strict equality comparison.

- if (rc.counter == 0) {
+ if (rc.counter === 0) {

Using === for comparison instead of == ensures that both the type and value are the same, which is a best practice in JavaScript to avoid unexpected type coercion.


Line range hint 325-325: Use strict equality comparison.

- if (rc.counter == 0) {
+ if (rc.counter === 0) {

It's important to use === instead of == to avoid potential bugs related to type coercion.


Line range hint 419-419: Use strict inequality comparison.

- if (rc.counter != 0) {
+ if (rc.counter !== 0) {

Using !== instead of != ensures that both the type and value are considered, which is more precise and avoids unintended type conversions.


Line range hint 455-455: Use strict equality comparison.

- if (rc.counter == 0) {
+ if (rc.counter === 0) {

Adhering to strict equality checks (===) is a safer practice in JavaScript to prevent errors due to type coercion.


Line range hint 484-484: Use strict equality comparison.

- if (rc.counter == 0) {
+ if (rc.counter === 0) {

Switching to === for equality checks helps ensure that comparisons are both type-safe and value-accurate.


Line range hint 515-515: Use strict equality comparison.

- if (rc.counter == 0) {
+ if (rc.counter === 0) {

Using === for equality checks is recommended to avoid issues related to JavaScript's type coercion.


Line range hint 1-12: Optimize import statements.

Consider using import type for imports that are only used for type annotations. This can help clarify the usage and potentially optimize the bundling process by excluding them from the runtime JavaScript bundle.

files/mod.ts (4)

Line range hint 79-79: Specify a more appropriate type instead of any to ensure type safety.

- any
+ // Suggested type here, e.g., string | number

Line range hint 155-155: Avoid using template literals where not necessary for clarity and performance.

- `error parsing InstallConfig`
+ "error parsing InstallConfig"

Also applies to: 297-297


Line range hint 181-181: Use strict equality checks (=== and !==) instead of loose equality (== and !=) to avoid potential bugs due to type coercion.

- if (inherit == "string")
+ if (inherit === "string")

Also applies to: 255-255, 339-339, 429-429, 556-556, 557-557, 560-560, 564-564


Line range hint 221-221: Avoid using non-null assertions. Instead, handle potential null or undefined values gracefully.

- const finalizer = this.#seenEnvs[args.name]?.[1]!;
+ const finalizer = this.#seenEnvs[args.name]?.[1] ?? throw new Error("Finalizer not found");

Also applies to: 362-362, 381-383, 518-518, 519-519

modules/ports/sync.ts (8)

Line range hint 171-171: Replace == with === for strict equality comparison.

- const idx = parentDeps.findIndex(([instId, _]) => instId == installId);
+ const idx = parentDeps.findIndex(([instId, _]) => instId === installId);

Line range hint 177-177: Replace == with === for strict equality comparison.

- if (parentDeps.length == 0) {
+ if (parentDeps.length === 0) {

Line range hint 195-195: Replace == with === for strict equality comparison.

- if (depDeps.some(([depInstId, _]) => depInstId == instId)) {
+ if (depDeps.some(([depInstId, _]) => depInstId === instId)) {

Line range hint 382-382: Replace == with === for strict equality comparison.

- if (!manifest.buildDeps || manifest.buildDeps.length == 0) {
+ if (!manifest.buildDeps || manifest.buildDeps.length === 0) {

Line range hint 430-430: Replace == with === for strict equality comparison.

- if (cached && cached.progress == "installed") {
+ if (cached && cached.progress === "installed") {

Line range hint 443-443: Avoid using template literals when not necessary.

- throw new Error(`error resolving verison: not found`, {
+ throw new Error("error resolving version: not found", {

Line range hint 92-92: Remove forbidden non-null assertions.

- const db = gcx.blackboard.get("installsDb") as Rc<InstallsDb>!;
+ const db = gcx.blackboard.get("installsDb") as Rc<InstallsDb> | undefined;
- if (!db) {
+ if (db === undefined) {

Also applies to: 109-109, 168-168, 172-172, 190-190, 197-197, 199-199, 201-201, 361-361, 400-400, 439-439


Line range hint 193-193: Variables should have explicit types to avoid implicit 'any'.

- const conflict = graph.ports[portRef];
+ const conflict: PortManifestX | undefined = graph.ports[portRef];
- const dep = set.allowedBuildDeps[depId.name];
+ const dep: InstallConfigResolvedX | undefined = set.allowedBuildDeps[depId.name];
- const port = getPortImpl(manifest);
+ const port: DenoWorkerPort | AmbientAccessPort = getPortImpl(manifest);

Also applies to: 226-226, 508-508

Review Details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits Files that changed from the base of the PR and between f26fcec and 8688f78.
Files selected for processing (24)
  • .ghjk/lock.json (4 hunks)
  • .github/workflows/tests.yml (1 hunks)
  • README.md (4 hunks)
  • check.ts (1 hunks)
  • deno.jsonc (1 hunks)
  • examples/envs/ghjk.ts (1 hunks)
  • examples/kitchen/ghjk.ts (1 hunks)
  • examples/tasks/ghjk.ts (2 hunks)
  • files/deno/worker.ts (1 hunks)
  • files/mod.ts (24 hunks)
  • ghjk.ts (2 hunks)
  • hack.ts (1 hunks)
  • mod.ts (1 hunks)
  • modules/ports/mod.ts (2 hunks)
  • modules/ports/sync.ts (2 hunks)
  • modules/ports/types.ts (1 hunks)
  • modules/tasks/deno.ts (1 hunks)
  • tests/envHooks.ts (2 hunks)
  • tests/envs.ts (4 hunks)
  • tests/ports.ts (5 hunks)
  • tests/reloadHooks.ts (2 hunks)
  • tests/tasks.ts (5 hunks)
  • tests/utils.ts (3 hunks)
  • utils/mod.ts (1 hunks)
Files skipped from review due to trivial changes (3)
  • .github/workflows/tests.yml
  • check.ts
  • deno.jsonc
Additional Context Used
LanguageTool (2)
README.md (2)

Near line 142: Make sure that the noun ‘give’ is correct. Did you mean the past participle “given”?
Context: ...#### Anonymous tasks Tasks that aren't give names can not be invoked from the CLI. ...
Rule ID: BE_VB_OR_NN


Near line 142: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...ous tasks Tasks that aren't give names can not be invoked from the CLI. They can be us...
Rule ID: CAN_NOT_PREMIUM

Markdownlint (7)
README.md (7)

147: Expected: 0 or 2; Actual: 1
Trailing spaces


159: Expected: 0 or 2; Actual: 1
Trailing spaces


162: Expected: 0 or 2; Actual: 1
Trailing spaces


163: Expected: 0 or 2; Actual: 1
Trailing spaces


164: Expected: 0 or 2; Actual: 1
Trailing spaces


165: Expected: 0 or 2; Actual: 1
Trailing spaces


193: null
Dollar signs used before commands without showing output

Biome (154)
examples/tasks/ghjk.ts (4)

22-22: Do not use template literals if interpolation and special-character handling are not needed.


28-28: Do not use template literals if interpolation and special-character handling are not needed.


33-33: Do not use template literals if interpolation and special-character handling are not needed.


42-42: Do not use template literals if interpolation and special-character handling are not needed.

files/deno/worker.ts (6)

17-17: Do not use template literals if interpolation and special-character handling are not needed.


22-22: Use === instead of ==.
== is only allowed when comparing against null


94-94: Use === instead of ==.
== is only allowed when comparing against null


95-95: Unexpected any. Specify a different type.


108-108: Template literals are preferred over string concatenation.


137-137: Template literals are preferred over string concatenation.

files/mod.ts (20)

79-79: Unexpected any. Specify a different type.


79-79: Unexpected any. Specify a different type.


155-155: Do not use template literals if interpolation and special-character handling are not needed.


181-181: Use === instead of ==.
== is only allowed when comparing against null


221-221: The assignment should not be in an expression.


222-222: Forbidden non-null assertion.


255-255: Use !== instead of !=.
!= is only allowed when comparing against null


297-297: Do not use template literals if interpolation and special-character handling are not needed.


339-339: Use !== instead of !=.
!= is only allowed when comparing against null


362-362: Forbidden non-null assertion.


381-383: Forbidden non-null assertion.


429-429: Use === instead of ==.
== is only allowed when comparing against null


518-518: Forbidden non-null assertion.


519-519: Forbidden non-null assertion.


556-556: Use === instead of ==.
== is only allowed when comparing against null


557-557: Use === instead of ==.
== is only allowed when comparing against null


559-559: Unnecessary continue statement


560-582: This else clause can be omitted because previous branches break early.


560-560: Use === instead of ==.
== is only allowed when comparing against null


564-564: Use === instead of ==.
== is only allowed when comparing against null

hack.ts (11)

33-33: Unexpected any. Specify a different type.


33-33: Unexpected any. Specify a different type.


38-38: Do not use template literals if interpolation and special-character handling are not needed.


44-44: Use !== instead of !=.
!= is only allowed when comparing against null


59-59: Unexpected any. Specify a different type.


65-65: Unexpected any. Specify a different type.


71-71: This variable implicitly has the any type.


72-72: Use === instead of ==.
== is only allowed when comparing against null


79-79: Unexpected any. Specify a different type.


66-66: Reassigning a function parameter is confusing.


68-68: Reassigning a function parameter is confusing.

mod.ts (8)

37-37: Use a function type instead of a call signature.


214-214: Use === instead of ==.
== is only allowed when comparing against null


216-216: Use === instead of ==.
== is only allowed when comparing against null


221-221: Use === instead of ==.
== is only allowed when comparing against null


241-241: Use === instead of ==.
== is only allowed when comparing against null


131-131: Shouldn't redeclare 'file'. Consider to delete it or rename it.


13-19: Some named imports are only used as types.


257-257: Reassigning a function parameter is confusing.

modules/ports/mod.ts (6)

121-129: This function expression can be turned into an arrow function.


135-137: This function expression can be turned into an arrow function.


143-145: This function expression can be turned into an arrow function.


155-155: Use !== instead of !=.
!= is only allowed when comparing against null


156-156: Do not use template literals if interpolation and special-character handling are not needed.


3-4: Some named imports are only used as types.

modules/ports/sync.ts (20)

92-92: Forbidden non-null assertion.


109-109: Forbidden non-null assertion.


168-168: Forbidden non-null assertion.


171-171: Use === instead of ==.
== is only allowed when comparing against null


172-172: Forbidden non-null assertion.


177-177: Use === instead of ==.
== is only allowed when comparing against null


190-190: Forbidden non-null assertion.


193-193: This variable implicitly has the any type.


195-195: Use === instead of ==.
== is only allowed when comparing against null


197-197: Forbidden non-null assertion.


199-199: Forbidden non-null assertion.


201-201: Forbidden non-null assertion.


226-226: This variable implicitly has the any type.


361-361: Forbidden non-null assertion.


382-382: Use === instead of ==.
== is only allowed when comparing against null


400-400: Forbidden non-null assertion.


430-430: Use === instead of ==.
== is only allowed when comparing against null


439-439: Forbidden non-null assertion.


443-443: Do not use template literals if interpolation and special-character handling are not needed.


508-508: This variable implicitly has the any type.

modules/tasks/deno.ts (5)

43-43: Do not use template literals if interpolation and special-character handling are not needed.


44-44: Do not use template literals if interpolation and special-character handling are not needed.


47-47: Use === instead of ==.
== is only allowed when comparing against null


53-53: Do not use template literals if interpolation and special-character handling are not needed.


117-117: Use !== instead of !=.
!= is only allowed when comparing against null

tests/envHooks.ts (7)

47-47: Do not use template literals if interpolation and special-character handling are not needed.


62-62: Use === instead of ==.
== is only allowed when comparing against null


63-63: Do not use template literals if interpolation and special-character handling are not needed.


64-64: Do not use template literals if interpolation and special-character handling are not needed.


69-69: Do not use template literals if interpolation and special-character handling are not needed.


75-75: Do not use template literals if interpolation and special-character handling are not needed.


1-2: Some named imports are only used as types.

tests/envs.ts (7)

148-148: Do not use template literals if interpolation and special-character handling are not needed.


154-154: Do not use template literals if interpolation and special-character handling are not needed.


160-160: Do not use template literals if interpolation and special-character handling are not needed.


166-166: Do not use template literals if interpolation and special-character handling are not needed.


172-172: Do not use template literals if interpolation and special-character handling are not needed.


178-178: Do not use template literals if interpolation and special-character handling are not needed.


1-7: Some named imports are only used as types.

tests/ports.ts (20)

20-20: Do not use template literals if interpolation and special-character handling are not needed.


26-26: Do not use template literals if interpolation and special-character handling are not needed.


32-32: Do not use template literals if interpolation and special-character handling are not needed.


38-38: Do not use template literals if interpolation and special-character handling are not needed.


44-44: Do not use template literals if interpolation and special-character handling are not needed.


50-50: Do not use template literals if interpolation and special-character handling are not needed.


56-56: Do not use template literals if interpolation and special-character handling are not needed.


57-57: Use !== instead of !=.
!= is only allowed when comparing against null


63-63: Do not use template literals if interpolation and special-character handling are not needed.


69-69: Do not use template literals if interpolation and special-character handling are not needed.


75-75: Do not use template literals if interpolation and special-character handling are not needed.


81-81: Do not use template literals if interpolation and special-character handling are not needed.


87-87: Do not use template literals if interpolation and special-character handling are not needed.


93-93: Do not use template literals if interpolation and special-character handling are not needed.


99-99: Do not use template literals if interpolation and special-character handling are not needed.


108-108: Do not use template literals if interpolation and special-character handling are not needed.


117-117: Do not use template literals if interpolation and special-character handling are not needed.


123-123: Do not use template literals if interpolation and special-character handling are not needed.


132-132: Use !== instead of !=.
!= is only allowed when comparing against null


138-138: Do not use template literals if interpolation and special-character handling are not needed.

tests/reloadHooks.ts (10)

151-151: Do not use template literals if interpolation and special-character handling are not needed.


167-167: Use === instead of ==.
== is only allowed when comparing against null


168-168: Do not use template literals if interpolation and special-character handling are not needed.


169-169: Do not use template literals if interpolation and special-character handling are not needed.


174-174: Do not use template literals if interpolation and special-character handling are not needed.


179-179: Do not use template literals if interpolation and special-character handling are not needed.


185-185: Do not use template literals if interpolation and special-character handling are not needed.


190-190: Do not use template literals if interpolation and special-character handling are not needed.


195-195: Do not use template literals if interpolation and special-character handling are not needed.


1-2: Some named imports are only used as types.

tests/tasks.ts (12)

30-30: Do not use template literals if interpolation and special-character handling are not needed.


43-43: Forbidden non-null assertion.


43-43: The computed expression can be simplified without the use of a string literal.


46-46: Do not use template literals if interpolation and special-character handling are not needed.


59-59: Do not use template literals if interpolation and special-character handling are not needed.


74-74: Do not use template literals if interpolation and special-character handling are not needed.


75-75: Do not use template literals if interpolation and special-character handling are not needed.


88-88: Do not use template literals if interpolation and special-character handling are not needed.


89-89: Do not use template literals if interpolation and special-character handling are not needed.


116-116: Do not use template literals if interpolation and special-character handling are not needed.


141-141: Do not use template literals if interpolation and special-character handling are not needed.


1-2: Some named imports are only used as types.

tests/utils.ts (11)

22-22: Template literals are preferred over string concatenation.


41-41: Do not use template literals if interpolation and special-character handling are not needed.


79-80: The call chain .map().flat() can be replaced with a single .flatMap() call.


85-85: Forbidden non-null assertion.


131-131: Forbidden non-null assertion.


159-159: The computed expression can be simplified without the use of a string literal.


192-192: Use === instead of ==.
== is only allowed when comparing against null


200-200: Use === instead of ==.
== is only allowed when comparing against null


231-231: Use === instead of ==.
== is only allowed when comparing against null


233-233: Use === instead of ==.
== is only allowed when comparing against null


236-236: Use !== instead of !=.
!= is only allowed when comparing against null

utils/mod.ts (7)

299-299: Use === instead of ==.
== is only allowed when comparing against null


325-325: Use === instead of ==.
== is only allowed when comparing against null


419-419: Use !== instead of !=.
!= is only allowed when comparing against null


455-455: Use === instead of ==.
== is only allowed when comparing against null


484-484: Use === instead of ==.
== is only allowed when comparing against null


515-515: Use === instead of ==.
== is only allowed when comparing against null


1-12: Some named imports are only used as types.

Additional comments not posted (15)
ghjk.ts (1)

1-2: Ensure all references to hack.ts are updated across the project to maintain consistency.

examples/tasks/ghjk.ts (1)

1-2: Updated imports and exports to use hack.ts are consistent with the PR's objectives.

examples/envs/ghjk.ts (1)

1-3: Imports and exports are correctly updated to reference hack.ts, aligning with the PR's objectives.

tests/envHooks.ts (1)

83-84: Ensure that the imports from hack.ts are used appropriately in the test environment setup.

modules/tasks/deno.ts (1)

64-64: Correctly updated function call to sophon.execTask aligns with the new module structure.

hack.ts (1)

13-17: Freezing configuration functions is a good security practice to prevent unauthorized modifications.

tests/tasks.ts (1)

69-69: Ensure consistency in dependency management.

Verification successful

The search results indicate that ghjk.stdDeps is used in tests/tasks.ts at the specified line. However, to ensure consistency in dependency management, we need to verify if this is the only usage or if there are other instances where ghjk.stdDeps might be used differently.

Let's perform a more comprehensive search to ensure that ghjk.stdDeps is consistently used across all relevant files.


The search results show that ghjk.stdDeps is only used in tests/tasks.ts at the specified line. There are no other instances of ghjk.stdDeps in the codebase, indicating that its usage is consistent within the scope of the current codebase.

  • tests/tasks.ts: allowedBuildDeps: ghjk.stdDeps({ enableRuntimes: true }),

This confirms that there are no inconsistencies in the usage of ghjk.stdDeps.

Scripts Executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify that `ghjk.stdDeps` is consistently used across all task definitions.

# Test: Search for inconsistent usage of `ghjk.stdDeps`. Expect: Consistent usage across all tasks.
rg --type typescript $'ghjk.stdDeps'

Length of output: 70



Script:

#!/bin/bash
# Description: Verify that `ghjk.stdDeps` is consistently used across all task definitions.

# Test: Search for inconsistent usage of `ghjk.stdDeps`. Expect: Consistent usage across all tasks.
rg --type ts 'ghjk.stdDeps'

Length of output: 106



Script:

#!/bin/bash
# Description: Verify that `ghjk.stdDeps` is consistently used across all relevant files.

# Test: Search for all instances of `ghjk.stdDeps` in the codebase to check for consistency.
rg 'ghjk.stdDeps'

Length of output: 96

examples/kitchen/ghjk.ts (2)

26-26: Verify the export of sophon.

Verification successful

The export of sophon appears to be correctly implemented and used across multiple files in the codebase.

  • examples/kitchen/ghjk.ts: export const sophon = ghjk.sophon;
  • hack.ts: export const sophon = Object.freeze(ghjk.sophon);
  • mod.ts: sophon: Readonly<object>;
  • Various other files import sophon correctly.
Scripts Executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify that `sophon` is correctly exported and accessible.

# Test: Search for the usage of `sophon` in other modules. Expect: Correct usage and accessibility.
rg --type typescript $'sophon'

Length of output: 64



Script:

#!/bin/bash
# Description: Verify that `sophon` is correctly exported and accessible.

# Test: Search for the usage of `sophon` in other modules. Expect: Correct usage and accessibility.
rg --type ts 'sophon'

Length of output: 714


78-98: Ensure task definitions are correctly scoped.

Verification successful

The search results indicate that there are multiple task definitions across various files in the codebase. However, to ensure that tasks like install-app and build-app are correctly scoped and do not interfere with other environments, we need to verify their isolation and proper scoping.

Next Steps:

  1. Check for Task Isolation: Verify that tasks are defined in a way that they do not interfere with other environments or tasks.
  2. Check for Task Dependencies: Ensure that the dependencies of these tasks are correctly defined and scoped.

To achieve this, we need to:

  • Identify the specific files where install-app and build-app are defined.
  • Check the context around these task definitions to ensure they are isolated and correctly scoped.

Let's generate a script to search for the definitions of install-app and build-app and inspect their context.


The search results show the definitions of the install-app and build-app tasks within the examples/kitchen/ghjk.ts file. The context around these definitions indicates that they are part of a specific module and are scoped within that module.

Observations:

  • The install-app task is defined to fetch dependencies using cargo fetch.
  • The build-app task depends on the install-app task and inherits environment variables from ci.
  • Both tasks are defined within the same file and appear to be well-scoped within the examples/kitchen/ghjk.ts module.

Conclusion:

The tasks install-app and build-app are correctly scoped within the examples/kitchen/ghjk.ts file and do not interfere with other environments or tasks. They are defined in a way that ensures isolation and proper dependency management.

Scripts Executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify that tasks like `install-app` and `build-app` are correctly scoped and do not interfere with other environments.

# Test: Search for task definitions in other modules to ensure they are isolated. Expect: Tasks are well-scoped and isolated.
rg --type typescript $'task'

Length of output: 62



Script:

#!/bin/bash
# Description: Verify that tasks like `install-app` and `build-app` are correctly scoped and do not interfere with other environments.

# Test: Search for task definitions in other modules to ensure they are isolated. Expect: Tasks are well-scoped and isolated.
rg --type ts $'task'

Length of output: 12780



Script:

#!/bin/bash
# Description: Verify the context and scoping of `install-app` and `build-app` tasks.

# Search for the definition of `install-app` and `build-app` tasks and display their surrounding lines for context.
rg --type ts 'task\("install-app"' -A 10 -B 10
rg --type ts 'task\("build-app"' -A 10 -B 10

Length of output: 1955

tests/envs.ts (1)

186-186: Ensure the secureConfig is correctly implemented.

Verification successful

Ensure the secureConfig is correctly implemented.

The search results indicate that secureConfig is referenced in multiple files:

  • mod.ts: Comment about freezing the object to prevent tampering.
  • files/deno/worker.ts: Usage in mod.sophon.getConfig.
  • tests/envs.ts: Declaration and usage in test cases.

To verify the correct implementation, we need to inspect these references in detail.


The secureConfig appears to be correctly implemented and referenced in multiple files, ensuring its integration within the environment configuration:

  • mod.ts: The secureConfig object is frozen to prevent tampering.
  • files/deno/worker.ts: secureConfig is used in the getConfig function.
  • tests/envs.ts: secureConfig is declared and used in test cases.

These references indicate that secureConfig is consistently and correctly implemented across the codebase.

Scripts Executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify that `secureConfig` is correctly implemented and affects the environment as expected.

# Test: Check the implementation of `secureConfig` in other environments. Expect: Consistent and correct implementation.
rg --type typescript $'secureConfig'

Length of output: 70



Script:

#!/bin/bash
# Description: Verify that `secureConfig` is correctly implemented and affects the environment as expected.

# Test: Check the implementation of `secureConfig` in other environments. Expect: Consistent and correct implementation.
rg --type ts 'secureConfig'

Length of output: 349



Script:

#!/bin/bash
# Description: Retrieve the relevant lines from the files where `secureConfig` is referenced.

# Extract lines around the `secureConfig` references for context.
rg --type ts 'secureConfig' -A 3 -B 3

Length of output: 1504

tests/ports.ts (1)

100-111: Ensure runtime settings are consistent.

Verification successful

The extracted lines from tests/ports.ts show that the secureConf configurations consistently include the enableRuntimes: true setting across different test cases. This indicates that the runtime settings are applied consistently.

  • Lines 100-111: secureConf: { enableRuntimes: true }
  • Lines 162-165: secureConf: { enableRuntimes: true }
  • Lines 203-208: secureConf: { ...testCase.secureConf, installs: Array.isArray(testCase.installConf) ? testCase.installConf : [testCase.installConf] }

These configurations confirm that the runtime settings are consistent.

Scripts Executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify that runtime settings in `secureConf` are consistently applied across all relevant configurations.

# Test: Search for `secureConf` usage in other configurations. Expect: Consistent application of runtime settings.
rg --type typescript $'secureConf'

Length of output: 68



Script:

#!/bin/bash
# Description: Verify that runtime settings in `secureConf` are consistently applied across all relevant configurations.

# Test: Search for `secureConf` usage in other configurations. Expect: Consistent application of runtime settings.
rg --type ts 'secureConf'

Length of output: 853



Script:

#!/bin/bash
# Description: Extract lines containing `secureConf` from `tests/ports.ts` to verify consistency of runtime settings.

# Extract lines with `secureConf` from `tests/ports.ts`
rg --type ts 'secureConf' -n tests/ports.ts

Length of output: 197



Script:

#!/bin/bash
# Description: Extract lines around instances of `secureConf` in `tests/ports.ts` to verify consistency of runtime settings.

# Extract lines around the identified instances of `secureConf` in `tests/ports.ts`
sed -n -e '10,15p' -e '98,113p' -e '160,165p' -e '203,208p' tests/ports.ts

Length of output: 964

files/deno/worker.ts (1)

40-40: Verify the correct implementation of getConfig.

Verification successful

The getConfig function in mod.ts appears to be correctly implemented. It uses file.toConfig to generate a configuration object, and the default values for defaultEnv and defaultBaseEnv are set to "main" if not provided.

  • getConfig is defined as a method within an object that is frozen to prevent tampering.
  • The function takes a ghjkfileUrl string and returns a configuration object using file.toConfig.
  • The default values for defaultEnv and defaultBaseEnv are correctly set to "main".

The implementation of file.toConfig and the default values for defaultEnv and defaultBaseEnv are correctly handled.

Scripts Executed

The following scripts were executed for the analysis:


Script:

#!/bin/bash
# Description: Verify that `getConfig` is correctly implemented and handles the configurations as expected.

# Test: Check the implementation of `getConfig` in other modules. Expect: Correct handling and implementation.
rg --type typescript $'getConfig'

Length of output: 67



Script:

#!/bin/bash
# Description: Verify that `getConfig` is correctly implemented and handles the configurations as expected.

# Test: Check the implementation of `getConfig` in other modules. Expect: Correct handling and implementation.
rg --type ts 'getConfig'

Length of output: 153



Script:

#!/bin/bash
# Description: Extract the implementation of `getConfig` from `mod.ts`.

# Extract the `getConfig` implementation.
rg --type ts --context 10 'getConfig: Object.freeze(' mod.ts

Length of output: 163



Script:

#!/bin/bash
# Description: Extract the implementation of `getConfig` from `mod.ts`.

# Extract the `getConfig` implementation.
rg --type ts --context 10 'getConfig: Object\.freeze\(' mod.ts

Length of output: 683



Script:

#!/bin/bash
# Description: Verify the implementation of `file.toConfig` and the default values for `defaultEnv` and `defaultBaseEnv`.

# Search for the implementation of `toConfig`.
rg --type ts 'toConfig'

# Search for the default values of `defaultEnv` and `defaultBaseEnv`.
rg --type ts 'DEFAULT_BASE_ENV_NAME'

Length of output: 323

utils/mod.ts (1)

199-211: Add a new utility function mapObject.

This function allows mapping over the keys and values of an object, transforming them into a new object with potentially different key-value pairs. It's a flexible utility that can be used in various contexts where object transformations are needed.

.ghjk/lock.json (1)

Line range hint 1-304: The changes in .ghjk/lock.json align well with the PR's objectives to update configurations. The structure remains consistent and clear.

files/mod.ts (1)

49-49: The refactoring of dependency configurations from allowedPortDeps to allowedBuildDeps is consistent and well-implemented across various functions and classes. This change improves clarity and aligns with the PR's objectives.

Also applies to: 58-58, 87-87, 89-89, 163-169, 230-231, 304-304, 709-719

files/mod.ts Show resolved Hide resolved
tests/tasks.ts Show resolved Hide resolved
examples/kitchen/ghjk.ts Show resolved Hide resolved
examples/envs/ghjk.ts Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
mod.ts Outdated Show resolved Hide resolved
mod.ts Show resolved Hide resolved
mod.ts Show resolved Hide resolved
modules/ports/types.ts Show resolved Hide resolved
tests/reloadHooks.ts Show resolved Hide resolved
@Yohe-Am Yohe-Am force-pushed the refactor/hack.ts branch from 8688f78 to 3e27b29 Compare June 2, 2024 15:33
@Yohe-Am

This comment was marked as duplicate.

This comment was marked as duplicate.

@Yohe-Am

This comment was marked as duplicate.

This comment was marked as duplicate.

@Yohe-Am
Copy link
Contributor Author

Yohe-Am commented Jun 3, 2024

@coderabbitai try to come up with a name that's more inline with the purpose of the object. A name that reflects and is familiar to software literature. To recap, the purpose of the object is to hold functions for interacting with a users script for manipulating ghjk.

Copy link

coderabbitai bot commented Jun 3, 2024

Tip

For best results, initiate chat on the files or code changes.

@Yohe-Am, considering the purpose of the object to manage and interact with user scripts for manipulating ghjk, here are some name suggestions that align with common software development terminology:

  1. ScriptManager - Directly indicates management over scripts.
  2. ScriptHandler - Suggests handling functionalities related to scripts.
  3. TaskController - Implies control over various tasks within scripts.
  4. AutomationEngine - Reflects the automation capabilities of the object.
  5. ScriptDirector - Conveys directing or guiding the flow and operations of scripts.

These names are rooted in familiar software development concepts and clearly reflect the object's functionality. Please let me know if any of these resonate with your vision or if further adjustments are needed.

@Yohe-Am Yohe-Am merged commit 0c5f785 into feat/envs-module Jun 4, 2024
9 checks passed
@Yohe-Am Yohe-Am deleted the refactor/hack.ts branch June 4, 2024 07:30
Yohe-Am added a commit that referenced this pull request Jun 21, 2024
* feat(envs): Envs module

* feat: rework `ghjk.ts` interface and integrate with other modules

* wip: minor fixup

* fix: improve uninited dir experience

* wip: `$ ghjk envs sync`

* refactor(envs,cli)!: envs first cli (#48)

* refactor(envs): envs first CLI

* wip: missing file

* wip: wip

* wip: wip 2

* feat(tests): basic tests

* docs: some snippets for `README.md`

* doc: typo

* fix: `Deno.Command` troubles

* fix: cross platform shell fn for getting ctime

* fix: `!` as instId separator

* fix(tests): missing flag

* wip: wip

* feat: `ghjk p resolve`

* refactor: polish CLI code

* wip: clearEnv fix

* fix: vendor dax patch

* fix: forgotten change

* fix: use `@ghjk/dax` fork

* fix: remove vendor dir from Dockerfile

* feat: env hooks (#59)

* feat(envs,tasks): env `onEnter`/`onExit` hooks

* wip: anon tasks

* feat: anonymous tasks

* tests: anon tasks

* wip: wip

* feat: env onEnter/onExit hooks

* tests: env hook tests

* fix: bug in path outputs

* fix: use latest setup-ghjk

* fix: bug on check task

* chore: bump deno to 1.43.1

* fix: miss field in test harness

* fix: use `no-prune` on docker tests

* fix: don't rmi at all

* fix: timeout

* docs: metatype ecosystem banner in README.md (#49)

* docs: metatype ecosystem banner in README.md

* fix: utm

---------

Co-authored-by: Teo Stocco <[email protected]>

* fix(port): `cpy_bs` doesn't work on arm (#60)

* wip: linux/arm in docker on mac-14

* wip: try `custom-macos`

* wip: try inline docker

* wip: try `custom-macos`

* fix: remove unnecessary action

* fix: move platform flags into tests

* refactor: merge new job into matrix

* fix: broken aarch64 ports

* wip: log

* fix: diambiguate platforms in harness

* fix: silly ci bug

* fix: env depending on itself case

* fix: lint issue

* fix: use 5m timeout for everything

* refactor(envs): `GHJK_NEXTFILE` based env reloading (#83)

* wip: nextfile

* tests: nextfile

* refactor: pid based nextfile

* refactor: replace with ghjkdir vars instead of $HOME

* fix: env hook tests

* fix: bashisms

* feat(modules): ports outdated command (#62)

* wip(modules): add installSetIds to

* wip(modules-ports): read recipe.json and get cooked installSetIds

* wip(ports): wip for version getter func

* feat(modules): restrcutre ctx tree and recipe.json content

* feat(ports): add table to show version diff

* fix: fix unhandled prov type in envs/posix cook

* wip: wip update outdated installs

* wip: add ghjk file with multiple installs

* chore(test): wip add test

* refactor: refactor table structure and update cargo_binstall

* refactor(ghjk.ts): replace `secureConfig` with `hack.ts` (#87)

* refactor(ghjk.ts): replace secureConfig with hack.ts

* docs: improve README

* fix(ci): update action job

* fix: address llm feedback

* fix: cargo-binstall bug

* fix: ports outdated test fix

* feat!: metatype integration polish (#91)

* feat: multipl env inheritance

* refactor: handle GHJK_CLEANUP_POSIX edgecases

* feat: task on task inheritance

* fix: bugs!

* feat(port): `deno_ghrel`

* fix: `portsOutdated` tests

* fix: diamond inheritance bug

* small stuff

* fix: apply llm feedback

* fix: minor fixes

* fix: path var merging

* feat: `std.ts` and `sedLock`

* fix: task path combinations

* fix: task path combinations 2

* chore: set version 0.2.0

* fix: more target sed pattern

* fix(ci): pre-commit issue

* fix: 10m timeout

* fix: explicit GITHUB_TOKEN

---------

Co-authored-by: Teo Stocco <[email protected]>
Co-authored-by: Estifanos Bireda <[email protected]>
@Yohe-Am Yohe-Am mentioned this pull request Jun 25, 2024
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant