feat(11ty): Eleventy v3対応 #181
Conversation
WalkthroughThe changes in this pull request primarily involve transitioning the codebase from CommonJS module syntax to ES module syntax across multiple files. The Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Application
participant JSONModule
User->>Application: Execute script
Application->>JSONModule: Dynamic import of JSON data
JSONModule-->>Application: Return JSON data
Application->>User: Display results
Possibly related PRs
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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (7)
src/site/_data/lastModifiedBlogsDate.js (2)
2-3: LGTM: Effective use of dynamic importThe transition to using dynamic import for loading the JSON feed data is appropriate and aligns well with the ES module syntax. This approach maintains the asynchronous nature of the function while simplifying the code.
Consider a minor optimization by combining the import and default export extraction:
const feedData = (await import('../feeds/feed.json')).default;This would reduce the code to a single line, making it slightly more concise.
5-5: LGTM with suggestion: Consider adding error handlingThe core logic for extracting and formatting the date remains correct and unchanged. However, to improve robustness, consider adding error handling for cases where
feedDataorfeedData.itemsmight be undefined or empty.Here's a suggested implementation with error handling:
export default async () => { const feedData = (await import('../feeds/feed.json')).default; if (!feedData || !feedData.items || feedData.items.length === 0) { throw new Error('Invalid or empty feed data'); } return new Date(feedData.items[0].date_published).toISOString(); };This change ensures that the function will throw a meaningful error if the feed data is not in the expected format, rather than potentially causing a runtime error.
src/site/_data/feedItemsChunks.js (2)
1-9: LGTM! Consider grouping related imports.The transition to ES6 import syntax is correct and aligns with modern JavaScript practices. The dayjs configuration is properly set up after the imports.
Consider grouping related imports for better readability:
import dayjs from 'dayjs'; import utc from 'dayjs/plugin/utc'; import timezone from 'dayjs/plugin/timezone'; import relativeTime from 'dayjs/plugin/relativeTime'; import 'dayjs/locale/ja';
13-15: LGTM! Consider caching for frequent calls.The transition to
export defaultand the use of dynamic import for JSON data are correct for ES modules.If this function is called frequently, consider caching the result of the dynamic import to improve performance:
let cachedFeedData; export default async () => { if (!cachedFeedData) { const feedDataModule = await import('../feeds/feed.json'); cachedFeedData = feedDataModule.default; } const feedData = cachedFeedData; // ... rest of the function };src/common/constants.ts (1)
Line range hint
1-38: Consider improvements for internationalization and user agent clarity.The constants are well-organized, but there are a couple of areas that could be improved:
- Internationalization: Consider adding English translations for comments in Japanese to improve accessibility for non-Japanese speakers. For example:
// Google Analytics関連。フォークして使う際は値を空にするか書き換えてください // Google Analytics related. When forking, please empty these values or replace them.
- User Agent Clarification: The
requestUserAgentincludes 'facebookexternalhit', which might need explanation or updating. Consider adding a comment explaining why this specific user agent is used or if it should be updated to reflect the current project.Would you like assistance in implementing these suggestions?
src/site/_data/blogFeeds.js (2)
1-6: LGTM! Consider combining dayjs plugin imports.The transition to ES module syntax is appropriate and aligns well with Eleventy v3. The imports are correctly structured.
For a minor optimization, consider combining the dayjs plugin imports:
import dayjs from 'dayjs'; import 'dayjs/locale/ja'; import { relativeTime, timezone, utc } from 'dayjs/plugin';This can slightly reduce the number of import statements.
Line range hint
13-50: LGTM! Consider adding error handling for dynamic import.The transition to ES module syntax and the use of dynamic import for the JSON file are appropriate changes. The core logic remains unchanged, which is good for maintaining consistency.
Consider adding error handling for the dynamic import to gracefully handle potential issues:
export default async () => { let blogFeeds; try { const blogFeedsModule = await import('../blog-feeds/blog-feeds.json'); blogFeeds = blogFeedsModule.default; } catch (error) { console.error('Error loading blog feeds:', error); blogFeeds = []; // or handle the error as appropriate for your use case } // Rest of the function remains the same // ... };This addition will make the function more robust by handling potential import errors.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (10)
- package.json (4 hunks)
- src/common/constants.ts (1 hunks)
- src/common/eleventy-cache-option.ts (1 hunks)
- src/site/_data/blogFeeds.js (1 hunks)
- src/site/_data/constants.js (1 hunks)
- src/site/_data/currentDate.js (1 hunks)
- src/site/_data/feedItemsChunks.js (1 hunks)
- src/site/_data/feedItemsHot.js (1 hunks)
- src/site/_data/lastModifiedBlogsDate.js (1 hunks)
- tsconfig.json (2 hunks)
✅ Files skipped from review due to trivial changes (1)
- src/common/eleventy-cache-option.ts
🔇 Additional comments (20)
src/site/_data/currentDate.js (1)
1-3: LGTM! The export syntax update aligns with Eleventy v3.The change from CommonJS to ES6 module syntax is appropriate for the Eleventy v3 update. The function implementation remains correct and unchanged.
To ensure all imports of this module have been updated, please run the following script:
Consider reviewing other files in the project for similar CommonJS to ES6 module syntax updates to ensure full compatibility with Eleventy v3. This change might be part of a larger refactoring effort.
src/site/_data/constants.js (2)
3-3: LGTM! Verify usage of constants.The export statement correctly uses ES6 module syntax, consistent with the import statement. Using a default export is appropriate if 'constants' is the main export of this module.
Let's verify the usage of 'constants' in other files:
#!/bin/bash # Search for imports of 'constants' in other files rg --type js "import .* from '.*constants\.js'" -g '!src/site/_data/constants.js'
1-3: Overall changes look good. Consider updating dependent files.The transition from CommonJS to ES6 module syntax is complete and consistent. This change aligns with the PR objective of updating to Eleventy v3.
Let's verify if other files need to be updated to use the new import syntax:
If the script returns any results, those files may need to be updated to use the new ES6 import syntax.
✅ Verification successful
Let's re-run the search with an improved pattern to accurately identify any files that still use CommonJS
requirestatements forconstants.
All dependent files use ES6 module syntax. Transition is fully complete.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for files that might need updating rg --type js "require\('.*constants'\)" -g '!src/site/_data/constants.js'Length of output: 81
Script:
#!/bin/bash # Search for CommonJS require statements importing 'constants' rg --type js "require\(['\"]\.{0,2}/?constants['\"]\)" -g '!src/site/_data/constants.js' # Additionally, check for CommonJS export patterns related to 'constants' rg --type js "module\.exports\s*=\s*constants" -g '!src/site/_data/constants.js'Length of output: 177
src/site/_data/lastModifiedBlogsDate.js (1)
1-1: LGTM: Appropriate transition to ES module syntaxThe change from
module.exportstoexport defaultis correct and aligns with the transition to ES modules. This update is consistent with modern JavaScript practices and supports Eleventy v3 compatibility.tsconfig.json (2)
28-28: Approve minor formatting improvementThe removal of the extra space before the closing bracket in the
includearray improves consistency in the file.
Line range hint
1-30: Verify Eleventy v3 TypeScript configuration recommendationsWhile the current changes appear sufficient for Eleventy v3 compatibility, it may be beneficial to verify if there are any additional TypeScript configuration options recommended for optimal use with Eleventy v3.
Please check the Eleventy v3 documentation or release notes for any specific TypeScript configuration recommendations. If found, consider updating the
tsconfig.jsonaccordingly.src/site/_data/feedItemsChunks.js (2)
7-11: LGTM! Dayjs configuration is correct.The dayjs plugins are properly extended, and the locale and timezone are correctly set. Keeping this configuration close to the imports is a good practice.
Line range hint
17-45: LGTM! Core logic remains correct and unchanged.The function's core logic, including filtering feed items for the last week, adjusting data with human-readable date formats, and creating feedItemsChunks, remains correct and unchanged.
src/common/constants.ts (1)
4-4: Approve the transition to ES6 module syntax.The change from
module.exportstoexport defaultis appropriate and aligns with modern JavaScript practices. This update is likely part of the transition to Eleventy v3 compatibility.To ensure this change doesn't break existing imports, please run the following script to check for any files that might need updating:
If any files are found, they may need to be updated to use the new import syntax:
import constants from '../path/to/constants';src/site/_data/blogFeeds.js (2)
7-11: LGTM! Dayjs configuration remains correct.The Dayjs configuration is unchanged and remains correct. It properly extends the necessary plugins and sets the locale and timezone.
Line range hint
1-50: Overall LGTM! Successfully updated to ES module syntax.The changes made to this file successfully transition it to ES module syntax, which aligns well with the PR objective of updating to Eleventy v3. The core functionality remains intact, and the modifications are appropriate. The use of dynamic import for the JSON file maintains asynchronous operation, which is a good practice.
A few minor suggestions were made for optimization and error handling, but these are not critical. The overall changes are approved and contribute positively to the modernization of the codebase.
src/site/_data/feedItemsHot.js (4)
1-5: LGTM! Improved module imports.The transition to ES module syntax is well-implemented and aligns with the PR objective of updating to Eleventy v3. Importing dayjs plugins separately is a good practice that can lead to better tree-shaking and potentially smaller bundle sizes.
7-9: LGTM! Consistent dayjs configuration.The dayjs plugin extensions have been updated to match the new import style while maintaining the same functionality. This change is consistent with the module syntax update.
Line range hint
1-55: Overall, excellent update to ES module syntax.The changes in this file successfully transition the code to ES module syntax, aligning with the PR objective of updating to Eleventy v3. The core functionality of filtering and sorting feed items remains intact, while the updates improve code modularity and potentially reduce bundle size through better tree-shaking.
Key improvements:
- Updated import statements for better modularity.
- Consistent dayjs configuration with the new import style.
- Modern approach to JSON data import using dynamic import.
These changes contribute positively to the codebase's maintainability and performance.
16-18: LGTM! Updated module export and JSON import.The changes to ES module export syntax and the use of dynamic import for JSON data are well-implemented and consistent with modern JavaScript practices. These updates align with the Eleventy v3 compatibility goal.
To ensure these changes don't introduce issues elsewhere in the codebase, please run the following verification script:
✅ Verification successful
Verification Successful!
All usages of
feedItemsHothave been updated to use ES module imports, and norequirecalls were found in the codebase, ensuring consistency with the changes.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of feedItemsHot module across the codebase # Test: Search for imports of feedItemsHot. Expect: ES module import syntax echo "Checking imports of feedItemsHot:" rg --type js "import.*feedItemsHot" -g '!src/site/_data/feedItemsHot.js' # Test: Search for require calls of feedItemsHot. Expect: No results echo "Checking require calls of feedItemsHot (should be empty):" rg --type js "require.*feedItemsHot" -g '!src/site/_data/feedItemsHot.js'Length of output: 352
package.json (5)
83-83: LGTM: tsx dependency added to support script changes.The addition of the 'tsx' devDependency is consistent with the script changes and supports the execution of TypeScript and ESM files. This aligns well with the project's move to ES modules.
Line range hint
1-103: Summary: Comprehensive update for Eleventy v3 and ES modules transitionThe changes in this file successfully update the project for Eleventy v3 compatibility and transition to ES modules. Key points:
- Scripts updated to use
tsxfor TypeScript and ESM execution.- Eleventy dependency updated to version 3.0.0.
- Added
tsxas a dev dependency.- Configured the project to use ES modules with
"type": "module".These changes are well-aligned with the PR objectives and represent a significant update to the project's structure. Ensure that all suggested verifications are performed to guarantee a smooth transition.
25-25: Approved: Project configured to use ES modules.The addition of
"type": "module"indicates that the project is now using ES modules instead of CommonJS. This is consistent with the script changes and the addition of the 'tsx' dependency.To ensure that all files in the project are compatible with ES modules, please run the following command:
#!/bin/bash # Description: Check for potential CommonJS syntax that needs to be updated # Test: Search for CommonJS require() and module.exports syntax # Expect: No output, indicating all files use ES module syntax rg -t js -t ts 'require\(|module\.exports'If the command returns any results, those files may need to be updated to use ES module import/export syntax.
8-11: LGTM: Script updates align with ES module usage.The change from
node --require esbuild-registertotsxacross all scripts is consistent and aligns with the project's move to ES modules. This simplifies the commands and potentially improves performance.To ensure all necessary scripts have been updated, please run the following command:
38-38: Approved: Eleventy updated to v3 as per PR objective.The update of @11ty/eleventy to version 3.0.0 aligns with the PR objective. This is a major version update and may introduce breaking changes.
Please review the Eleventy v3 changelog for any breaking changes that may affect the project. You can find the changelog at: https://github.com/11ty/eleventy/releases/tag/v3.0.0
To ensure all Eleventy-related files have been updated accordingly, run the following command:
Review the output files to ensure they are compatible with Eleventy v3.
yamadashy
force-pushed
the
feature/eleventy-v3
branch
from
b1cdb0b to
edf59ed
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (10)
- package.json (3 hunks)
- src/common/constants.ts (1 hunks)
- src/common/eleventy-cache-option.ts (1 hunks)
- src/site/_data/blogFeeds.js (1 hunks)
- src/site/_data/constants.js (1 hunks)
- src/site/_data/currentDate.js (1 hunks)
- src/site/_data/feedItemsChunks.js (1 hunks)
- src/site/_data/feedItemsHot.js (1 hunks)
- src/site/_data/lastModifiedBlogsDate.js (1 hunks)
- tsconfig.json (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (9)
- src/common/constants.ts
- src/common/eleventy-cache-option.ts
- src/site/_data/blogFeeds.js
- src/site/_data/constants.js
- src/site/_data/currentDate.js
- src/site/_data/feedItemsChunks.js
- src/site/_data/feedItemsHot.js
- src/site/_data/lastModifiedBlogsDate.js
- tsconfig.json
🔇 Additional comments (3)
package.json (3)
8-11: Approve script changes to usetsxThe switch from
node --require esbuild-registertotsxfor executing TypeScript files is a good improvement.tsxis a more efficient and modern approach for running TypeScript in Node.js environments, offering better performance and ESM support. This change aligns well with the upgrade to Eleventy v3 and the addition of"type": "module"to the package.json.
63-63: Approve addition oftsxdependencyThe addition of
tsx(version ^4.19.1) as a dependency is appropriate and consistent with the changes made to the script commands.tsxis a powerful tool for executing TypeScript and ESM files, offering improved performance and compatibility with both CommonJS and ES modules. This addition supports the transition to usingtsxin the npm scripts and aligns well with the project's move towards ES modules.
24-24: Approve addition of"type": "module"The addition of
"type": "module"to package.json is a significant change that indicates the project is now using ES modules by default. This aligns well with the upgrade to Eleventy v3 and modern JavaScript practices. However, this change may require adjustments to import/export statements throughout the project.To ensure compatibility, please run the following command to check for any syntax errors related to module imports/exports:
#!/bin/bash # Check for syntax errors in all TypeScript files find . -name "*.ts" -not -path "./node_modules/*" -print0 | xargs -0 -n1 tsx --no-warnings --no-cache
yamadashy
force-pushed
the
feature/eleventy-v3
branch
from
edf59ed to
54c27e3
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
src/site/_data/blogFeeds.js (3)
1-5: LGTM! Consider combining dayjs plugin imports.The transition to ES6 import syntax is well-implemented and aligns with modern JavaScript practices. Importing only the necessary plugins and locale is a good approach for optimizing bundle size.
For slightly improved readability, consider combining the dayjs plugin imports:
import dayjs from 'dayjs'; import 'dayjs/locale/ja'; import { relativeTime, timezone, utc } from 'dayjs/plugin';This change is optional and doesn't affect functionality.
13-15: LGTM! Consider using object destructuring for JSON import.The transition to ES6 export syntax and the use of dynamic import for the JSON file are well-implemented. These changes align with modern JavaScript practices and ES module standards.
For a slight optimization, consider using object destructuring in the import statement:
const { default: blogFeeds } = await import('../blog-feeds/blog-feeds.json');This eliminates the need for the separate assignment on the next line.
Line range hint
17-50: Consider adding error handling and optimizing performance.While the main logic of the function remains unchanged and appears to be working as intended, there are a few suggestions for improvement:
Error Handling: Consider adding try-catch blocks around the main processing logic to handle potential errors gracefully, especially when dealing with external data.
Performance Optimization: For large datasets, consider using
mapandfilteroperations instead offor...ofloops, which could potentially improve performance.Immutability: Consider using immutable operations (like
map) instead of modifying theblogFeedsarray in-place.Here's an example of how you might refactor the main processing logic:
export default async () => { try { const { default: blogFeeds } = await import('../blog-feeds/blog-feeds.json'); const processedFeeds = blogFeeds.map(blogFeed => { const lastUpdated = blogFeed.items[0]?.isoDate; const processedItems = blogFeed.items.map(feedItem => ({ ...feedItem, diffDateForHuman: dayjs().to(feedItem.isoDate), pubDateForHuman: dayjs(feedItem.isoDate).format('YYYY-MM-DD HH:mm:ss') })); return { ...blogFeed, items: processedItems, ...(lastUpdated && { lastUpdated, diffLastUpdatedDateForHuman: dayjs().to(lastUpdated), lastUpdatedForHuman: dayjs(lastUpdated).tz().format('YYYY-MM-DD HH:mm:ss'), lastUpdatedIso: new Date(lastUpdated).toISOString() }) }; }); return processedFeeds.sort((a, b) => (b.lastUpdated || '').localeCompare(a.lastUpdated || '') ); } catch (error) { console.error('Error processing blog feeds:', error); return []; } };This refactored version uses more functional programming concepts, adds basic error handling, and avoids in-place mutations of the data.
eleventy.config.ts (1)
Line range hint
1-185: Consider leveraging Eleventy v3 features and best practicesWhile the type changes might be necessary for Eleventy v3 compatibility, the lack of functional changes in the configuration suggests that we might be missing opportunities to leverage new features or best practices introduced in Eleventy v3.
- Review the Eleventy v3 changelog and documentation to identify any new features or recommended practices that could benefit our project.
- Consider updating the configuration to use any new APIs or options provided by Eleventy v3.
- If there are performance improvements or new capabilities in v3, evaluate how we can take advantage of them in our project.
To help with this, let's fetch the latest Eleventy documentation:
#!/bin/bash # Fetch latest Eleventy documentation echo "Fetching latest Eleventy documentation..." curl -s https://www.11ty.dev/docs/ | grep -oP '(?<=<h3 id=").*(?=">)' | sed 's/-/ /g'Review the output to identify any new features or best practices that we should consider implementing in our configuration.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (13)
- eleventy.config.ts (2 hunks)
- package.json (3 hunks)
- src/common/constants.ts (1 hunks)
- src/common/eleventy-cache-option.ts (1 hunks)
- src/feed/register-index-command.ts (1 hunks)
- src/feed/utils/feed-generator.ts (1 hunks)
- src/site/_data/blogFeeds.js (1 hunks)
- src/site/_data/constants.js (1 hunks)
- src/site/_data/currentDate.js (1 hunks)
- src/site/_data/feedItemsChunks.js (1 hunks)
- src/site/_data/feedItemsHot.js (1 hunks)
- src/site/_data/lastModifiedBlogsDate.js (1 hunks)
- tsconfig.json (1 hunks)
✅ Files skipped from review due to trivial changes (2)
- src/feed/register-index-command.ts
- src/feed/utils/feed-generator.ts
🚧 Files skipped from review as they are similar to previous changes (9)
- package.json
- src/common/constants.ts
- src/common/eleventy-cache-option.ts
- src/site/_data/constants.js
- src/site/_data/currentDate.js
- src/site/_data/feedItemsChunks.js
- src/site/_data/feedItemsHot.js
- src/site/_data/lastModifiedBlogsDate.js
- tsconfig.json
🔇 Additional comments (3)
src/site/_data/blogFeeds.js (1)
7-11: LGTM! Proper dayjs configuration.The dayjs configuration is correctly implemented. Extending the necessary plugins, setting the locale to Japanese, and configuring the default timezone to 'Asia/Tokyo' ensures consistent and localized date handling throughout the application.
eleventy.config.ts (2)
152-153:⚠️ Potential issueReconsider using
anytype for the main configuration objectThe type annotation for the main
eleventyConfigobject has been changed fromEleventy.UserConfigtoany. This change, while potentially necessary for Eleventy v3 compatibility, significantly reduces type safety for the entire configuration.
- If this change is indeed required for Eleventy v3, consider adding a comment explaining why, to prevent future confusion.
- Investigate if there's a more specific type provided by Eleventy v3 that we could use instead of
any.- If
anyis unavoidable, consider creating a custom type that includes the properties you're using fromeleventyConfig. This would provide better type safety thanany.Let's verify the Eleventy version and available types:
#!/bin/bash # Check Eleventy version and available types echo "Eleventy version:" grep '"@11ty/eleventy"' package.json echo "\nAvailable Eleventy types:" rg --type typescript "import.*from.*@11ty/eleventy" -A 10Based on the results, we can determine if there are more appropriate types available for use.
138-139:⚠️ Potential issueConsider maintaining type safety for
eleventyConfigThe type annotation for
eleventyConfighas been changed fromEleventy.UserConfigtoany, which reduces type safety. While this change might be necessary for compatibility with Eleventy v3, it could potentially lead to runtime errors that were previously caught by TypeScript.Could you provide more context on why this change was necessary? If it's related to Eleventy v3 compatibility, are there any types provided by the new version that we could use instead of
any?To verify the necessity of this change, let's check if
Eleventy.UserConfigis still available in the new version:If
Eleventy.UserConfigis still available, consider using it or a more specific type provided by Eleventy v3.
yamadashy
force-pushed
the
feature/eleventy-v3
branch
from
d90f00f to
baa72f1
Compare
yamadashy
force-pushed
the
feature/eleventy-v3
branch
from
baa72f1 to
b1c40b6
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
src/feed/generate-feed-command.ts (1)
Line range hint
1-85: Summary: Successfully updated for ES module compatibility.The changes in this file focus on updating the way directory paths are obtained, replacing
__dirnamewith a more compatible approach usingurl.fileURLToPath()andimport.meta.url. These modifications enhance the compatibility with ES modules, which is likely a requirement for Eleventy v3.The core functionality of the feed generation process remains unchanged, ensuring that the update maintains the existing behavior while improving compatibility.
Consider adding a comment explaining the reason for using
url.fileURLToPath()instead of__dirname, to help future maintainers understand the rationale behind this change.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (15)
- eleventy.config.ts (2 hunks)
- package.json (3 hunks)
- src/common/constants.ts (1 hunks)
- src/common/eleventy-cache-option.ts (1 hunks)
- src/feed/generate-feed-command.ts (1 hunks)
- src/feed/register-index-command.ts (1 hunks)
- src/feed/utils/feed-generator.ts (1 hunks)
- src/feed/utils/logger.ts (1 hunks)
- src/site/_data/blogFeeds.js (1 hunks)
- src/site/_data/constants.js (1 hunks)
- src/site/_data/currentDate.js (1 hunks)
- src/site/_data/feedItemsChunks.js (1 hunks)
- src/site/_data/feedItemsHot.js (1 hunks)
- src/site/_data/lastModifiedBlogsDate.js (1 hunks)
- tsconfig.json (1 hunks)
✅ Files skipped from review due to trivial changes (1)
- src/feed/utils/logger.ts
🚧 Files skipped from review as they are similar to previous changes (13)
- eleventy.config.ts
- package.json
- src/common/constants.ts
- src/common/eleventy-cache-option.ts
- src/feed/register-index-command.ts
- src/feed/utils/feed-generator.ts
- src/site/_data/blogFeeds.js
- src/site/_data/constants.js
- src/site/_data/currentDate.js
- src/site/_data/feedItemsChunks.js
- src/site/_data/feedItemsHot.js
- src/site/_data/lastModifiedBlogsDate.js
- tsconfig.json
🔇 Additional comments (3)
src/feed/generate-feed-command.ts (3)
2-2: LGTM: Proper import of theurlmodule.The addition of the
urlmodule import is correct and follows best practices by using thenode:prefix for built-in modules.
10-11: LGTM: Proper definition ofdirNamefor ES module compatibility.The addition of
dirNameusingurl.fileURLToPath()andimport.meta.urlis a correct approach for obtaining the directory path in an ES module context. This change enhances compatibility with environments where__dirnameis not available.
18-19: LGTM: Consistent update of directory paths.The updates to
STORE_FEEDS_DIR_PATHandSTORE_BLOG_FEEDS_DIR_PATHare correct and consistent with the earlier definition ofdirName. This change maintains the original directory structure while enhancing compatibility with ES modules.To ensure that these are the only instances where
__dirnamewas used, let's run the following verification script:✅ Verification successful
Verification Successful: No remaining
__dirnameinstances found.All instances of
__dirnamehave been successfully updated. No remaining usages detected in the codebase.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining instances of __dirname in the codebase # Test: Search for __dirname. Expect: No results rg --type typescript '__dirname'Length of output: 67
Script:
#!/bin/bash # Description: Check for any remaining instances of __dirname in TypeScript files # Test: Search for __dirname in .ts files rg --type ts '__dirname' # Test: Search for __dirname in .tsx files rg --type tsx '__dirname'Length of output: 78
Script:
#!/bin/bash # Description: Check for any remaining instances of __dirname in TypeScript files (.ts and .tsx) # Test: Search for __dirname in .ts and .tsx files rg '__dirname' --glob '*.ts' --glob '*.tsx'Length of output: 43
related: #156
Summary by CodeRabbit
New Features
Bug Fixes
Chores
@11ty/eleventydependency to version^3.0.0.@11ty/eleventy-fetchto version^4.0.1.@11ty/eleventy-imgto version^5.0.0.tsxas a new development dependency for streamlined TypeScript execution.