Skip to content
This repository has been archived by the owner on Sep 26, 2024. It is now read-only.

Reactor cleanup for use in eval project #191

Merged
merged 2 commits into from
Sep 25, 2024
Merged

Conversation

jonathankap
Copy link
Contributor

@jonathankap jonathankap commented Sep 22, 2024

  1. It turns out ESM modules want your imports to specify a file extension, so I've switched all imports to include .js
  2. When running outside a browser, a top-level document might not be defined (or might be inconsistent), so switch to consistently using window.document

Summary by CodeRabbit

  • New Features

    • Updated import paths across various modules to include .js file extensions, enhancing compatibility with environments that require explicit file references.
  • Bug Fixes

    • Clarified the scope of the document object by using window.document in multiple instances, ensuring consistent context in document manipulation.
  • Documentation

    • Updated tsconfig.json to enforce strict type-checking and consistent casing in file names, improving overall code quality and maintainability.

@jonathankap jonathankap requested a review from elg0nz September 22, 2024 20:28
Copy link

coderabbitai bot commented Sep 22, 2024

Walkthrough

Walkthrough

The pull request primarily updates import statements across various files in the packages/reactor directory to include the .js file extension. This change standardizes how modules are referenced, ensuring explicit file extensions are used. Additionally, there are modifications to the usage of the document object, where references are prefixed with window to clarify the context. The tsconfig.json file has also been updated to enforce stricter type-checking and consistent casing in file names.

Changes

Files Change Summary
packages/reactor/index.ts Updated import paths for interfaces and reactor to include .js extension.
packages/reactor/interfaces.ts Changed import of generateRandomString to include .js extension.
packages/reactor/main.ts Updated import paths for interfaces, modifications, and utils to include .js extension.
packages/reactor/modifications.ts Updated various import paths to include .js extension and changed document to window.document.
packages/reactor/modifications/*.ts Updated import paths for AppliableModification to include .js extension in multiple files.
packages/reactor/mutationObserver.ts Updated import paths for Reactor and modifications to include .js extension; document references changed to window.document.
packages/reactor/reactor.ts Updated import paths for several modules to include .js extension.
packages/reactor/tests/*.test.ts Changed document references to window.document in test setups.
packages/reactor/tsconfig.json Added "strict": true and "forceConsistentCasingInFileNames": true options.
packages/reactor/utils.ts Updated import path for ModificationRequest to include .js extension.

Possibly related PRs

  • feature/moc 19 create image replacer pt3 #62: The changes in this PR involve updating import statements to include .js file extensions, which is directly related to the changes made in the main PR that also updates import paths to include file extensions.

Suggested reviewers

  • elg0nz

Poem

🐇 In the code where rabbits hop,
Imports now have a .js stop.
With window clear, our paths align,
Type safety's here, all will be fine!
Let's celebrate with a joyful cheer,
For cleaner code, we hold so dear! 🎉


Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between eaaa9da and 81b2997.

Files selected for processing (18)
  • packages/reactor/index.ts (1 hunks)
  • packages/reactor/interfaces.ts (1 hunks)
  • packages/reactor/main.ts (1 hunks)
  • packages/reactor/modifications.ts (3 hunks)
  • packages/reactor/modifications/adjacentHTML.ts (1 hunks)
  • packages/reactor/modifications/highlight.ts (1 hunks)
  • packages/reactor/modifications/noop.ts (1 hunks)
  • packages/reactor/modifications/remove.ts (1 hunks)
  • packages/reactor/modifications/replace.ts (1 hunks)
  • packages/reactor/modifications/replaceAll.ts (3 hunks)
  • packages/reactor/modifications/swapImage.ts (1 hunks)
  • packages/reactor/modifications/toast.ts (1 hunks)
  • packages/reactor/mutationObserver.ts (3 hunks)
  • packages/reactor/reactor.ts (1 hunks)
  • packages/reactor/tests/modifications.test.ts (1 hunks)
  • packages/reactor/tests/mutation.test.ts (1 hunks)
  • packages/reactor/tsconfig.json (1 hunks)
  • packages/reactor/utils.ts (1 hunks)
Files skipped from review due to trivial changes (12)
  • packages/reactor/index.ts
  • packages/reactor/interfaces.ts
  • packages/reactor/main.ts
  • packages/reactor/modifications/adjacentHTML.ts
  • packages/reactor/modifications/highlight.ts
  • packages/reactor/modifications/noop.ts
  • packages/reactor/modifications/remove.ts
  • packages/reactor/modifications/replace.ts
  • packages/reactor/modifications/swapImage.ts
  • packages/reactor/modifications/toast.ts
  • packages/reactor/reactor.ts
  • packages/reactor/utils.ts
Additional comments not posted (13)
packages/reactor/tsconfig.json (1)

11-12: LGTM! The added TypeScript compiler options are beneficial.

The changes made to the tsconfig.json file are positive additions:

  1. "strict": true: Enabling strict type-checking is a good practice that can help catch potential type-related issues early in the development process. It enforces stricter type rules and promotes better type safety across the codebase.

  2. "forceConsistentCasingInFileNames": true: This option ensures that the casing of referenced file names matches the actual file names on disk. It helps prevent issues that may arise due to inconsistencies, especially when working with case-sensitive file systems.

These options align with TypeScript best practices and can improve the overall reliability and maintainability of the project.

packages/reactor/tests/mutation.test.ts (1)

14-14: LGTM! The change improves code clarity and consistency.

Prefixing document with window clarifies the context in which the document object is being accessed. This change aligns with the PR objective of using window.document consistently throughout the codebase to ensure predictable behavior across different execution environments.

The change does not alter the functionality of the code, as document and window.document refer to the same object in a browser environment. Overall, this change enhances code readability and maintainability.

packages/reactor/mutationObserver.ts (3)

1-3: LGTM!

The import statements have been correctly updated to include the .js file extension, adhering to the ECMAScript Modules (ESM) requirements. This change improves the compatibility and reliability of the code in the eval project.


45-45: LGTM!

The reference to document.createTreeWalker has been correctly updated to window.document.createTreeWalker, explicitly referencing the window object. This change improves the handling of the document object in various execution contexts and enhances the compatibility and reliability of the code in the eval project.


71-71: LGTM!

The reference to document.createTreeWalker has been correctly updated to window.document.createTreeWalker, explicitly referencing the window object. This change improves the handling of the document object in various execution contexts and enhances the compatibility and reliability of the code in the eval project.

packages/reactor/modifications.ts (4)

1-7: LGTM!

The import statements have been updated to include the .js file extension, which aligns with the ESM standard and improves clarity. The relative import paths remain unchanged, indicating that the file structure has not been modified.


16-16: LGTM!

The import statement for the interfaces.js file has been updated to include the .js file extension, ensuring consistency with the ESM standard and explicit file extension usage.


73-75: LGTM!

The usage of window.document.evaluate instead of doc.evaluate ensures that the document object is explicitly tied to the window context, clarifying the scope and ensuring consistency across different execution environments.

Additionally, prefixing the mod.xpath with //html if it doesn't already start with it ensures that the XPath expression is evaluated relative to the root <html> element, providing a consistent starting point for the evaluation.


204-204: LGTM!

The usage of window.document.evaluate instead of document.evaluate ensures that the document object is explicitly tied to the window context, clarifying the scope and ensuring consistency across different execution environments.

Additionally, passing window.document as the second argument to evaluate specifies the context node for the XPath expression evaluation, ensuring that the expression is evaluated relative to the entire document.

packages/reactor/modifications/replaceAll.ts (3)

1-1: LGTM!

The import statement has been correctly updated to include the .js file extension, which aligns with the PR objective of ensuring ESM compatibility.


Line range hint 109-122: LGTM!

The document.createTreeWalker method call has been correctly updated to window.document.createTreeWalker, which aligns with the PR objective of ensuring clarity and consistency when referencing the document object.


198-198: LGTM!

The document.createTextNode method call has been correctly updated to window.document.createTextNode, which aligns with the PR objective of ensuring clarity and consistency when referencing the document object.

packages/reactor/tests/modifications.test.ts (1)

14-14: LGTM!

The change clarifies the context of the document object by explicitly referencing the window object. This improves the reliability and predictability of the code when running in different environments.


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>, please review it.
    -- 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 gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    -- @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 using 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.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration 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.

Copy link
Contributor

@elg0nz elg0nz left a comment

Choose a reason for hiding this comment

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

Maybe adding a vite.config.ts to handle transpiling to ESM would be a better option, but given that we’re only using Reactor in two places and are close to feature completion, it might be overkill. I’ll leave the decision up to you; either path works for me! 😊

import { defineConfig } from 'vite';
import typescript from '@vitejs/plugin-typescript';
import path from 'path';

export default defineConfig({
  plugins: [typescript()],
  resolve: {
    extensions: ['.ts', '.js'],  // Resolve .ts and .js files automatically
    alias: {
      '@': path.resolve(__dirname, './src'),  // Example alias for cleaner imports
    },
  },
  build: {
    rollupOptions: {
      output: {
        entryFileNames: '[name].js',  // Ensure output filenames have .js extension
        chunkFileNames: '[name]-[hash].js',
        assetFileNames: '[name]-[hash].[ext]',
      },
    },
  },
});

@jonathankap
Copy link
Contributor Author

Maybe adding a vite.config.ts to handle transpiling to ESM would be a better option, but given that we’re only using Reactor in two places and are close to feature completion, it might be overkill. I’ll leave the decision up to you; either path works for me! 😊

import { defineConfig } from 'vite';
import typescript from '@vitejs/plugin-typescript';
import path from 'path';

export default defineConfig({
  plugins: [typescript()],
  resolve: {
    extensions: ['.ts', '.js'],  // Resolve .ts and .js files automatically
    alias: {
      '@': path.resolve(__dirname, './src'),  // Example alias for cleaner imports
    },
  },
  build: {
    rollupOptions: {
      output: {
        entryFileNames: '[name].js',  // Ensure output filenames have .js extension
        chunkFileNames: '[name]-[hash].js',
        assetFileNames: '[name]-[hash].[ext]',
      },
    },
  },
});

I added a ticket to deal with this in the future

@jonathankap jonathankap merged commit cb5f88f into main Sep 25, 2024
2 checks passed
@jonathankap jonathankap deleted the reactor_cleanup_09222024 branch September 25, 2024 16:21
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants