Chore: Performance optimization in dev experience#344
Chore: Performance optimization in dev experience#344joacotornello wants to merge 4 commits intomasterfrom
Conversation
📝 WalkthroughWalkthroughAdds dev setup scripts to check/build foundational packages and start Storybook, updates npm scripts and docs, expands Turbo pipeline targets and dependencies, and adjusts Webpack development configuration (resolution, caching, parallelism, optimizations, TypeScript loader options) plus plugin behaviors for robustness and concurrency. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Dev as Developer
participant NPM as npm/yarn
participant DS as .scripts/dev-setup.js
participant FS as FileSystem
participant Pkg as Foundational Pkgs<br/>(tokens, icons)
participant SB as Storybook
Dev->>NPM: run start:dev
NPM->>DS: node .scripts/dev-setup.js
DS->>FS: check dist paths for tokens/icons
alt any missing
DS->>Pkg: exec build command(s)
note over Pkg: Build each missing package\n(stderr/stdout inherited)
alt build fail
Pkg-->>DS: non-zero exit
DS-->>NPM: exit 1 (log error)
NPM-->>Dev: process exits
else build succeed
Pkg-->>DS: done
DS->>SB: storybook dev -p 6006
SB-->>Dev: UI available on 6006
end
else none missing
DS->>SB: storybook dev -p 6006
SB-->>Dev: UI available on 6006
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Suggested labels
Pre-merge checks (2 warnings, 1 inconclusive)❌ Failed Checks (2 warnings, 1 inconclusive)
✨ Finishing Touches
🧪 Generate unit tests
Comment |
Getting startedPlease make sure you read our documentation on how to write code for components, stories and styles.
|
joacotornello
changed the title
|
🚀✨ Your Storybook preview is ready! Happy reviewing! 🎉 |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 14
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
.yarn/versions/9e963b61.ymlis excluded by!**/.yarn/**
📒 Files selected for processing (11)
.scripts/dev-setup.js(1 hunks).scripts/setup-foundations.js(1 hunks)docs/DEVELOPMENT_SETUP.md(1 hunks)package.json(1 hunks)packages/core/webpack/src/config/base.ts(1 hunks)packages/core/webpack/src/config/development.ts(1 hunks)packages/core/webpack/src/plugins/MoveFilesIntoDistFolderPlugin.ts(1 hunks)packages/core/webpack/src/plugins/dtsBundleGeneratorPlugin.ts(2 hunks)packages/core/webpack/src/rules/common.ts(1 hunks)packages/core/webpack/src/utils/helpers.ts(2 hunks)turbo.json(1 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
!packages/icons/src/assets/*.svg
📄 CodeRabbit inference engine (.cursor/rules/icon-creation.mdc)
Do not place icon files outside of
packages/icons/src/assets.
Files:
docs/DEVELOPMENT_SETUP.mdpackages/core/webpack/src/plugins/MoveFilesIntoDistFolderPlugin.tspackages/core/webpack/src/config/base.tspackages/core/webpack/src/utils/helpers.tspackage.jsonpackages/core/webpack/src/rules/common.ts.scripts/setup-foundations.jspackages/core/webpack/src/plugins/dtsBundleGeneratorPlugin.ts.scripts/dev-setup.jspackages/core/webpack/src/config/development.tsturbo.json
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/code.mdc)
**/*.{ts,tsx}: Enforce type safety—never use any or unsafe casts, and always declare explicit types. When a dynamic type is truly unavoidable, use unknown and narrow it explicitly. Never use any for props or state.
Replace magic numbers with named constants.
Always use strict equality operators (===, !==) instead of loose ones.
Ensure functions have consistent return types.
Avoid using deprecated APIs.
Ban the use of eval() entirely.
Handle exceptions properly; never swallow errors silently.
Omit unnecessary else branches after a return.
Refactor functions that exceed the acceptable cyclomatic complexity threshold >10.
Export only intended symbols; keep internals private.
Prefer RegExp.exec() over String.match().
Always provide default cases in switch statements.
Prefer for…of (or Array higher-order methods such as .map, .filter) over classic for loops where appropriate. Avoid for…in on arrays.
Avoid deeply nested code by extracting logic into functions.
Files:
packages/core/webpack/src/plugins/MoveFilesIntoDistFolderPlugin.tspackages/core/webpack/src/config/base.tspackages/core/webpack/src/utils/helpers.tspackages/core/webpack/src/rules/common.tspackages/core/webpack/src/plugins/dtsBundleGeneratorPlugin.tspackages/core/webpack/src/config/development.ts
⚙️ CodeRabbit configuration file
**/*.{ts,tsx}: Review the React and TypeScript code for adherence to component design system best practices, including:
- Component reusability, composability, and proper prop interfaces
- Consistent usage of @nimbus-ds/styles package for styling and theming
- Accessibility compliance (WCAG guidelines, ARIA attributes, keyboard navigation)
- Cross-browser compatibility and progressive enhancement
- Maintain comprehensive JSDoc comments with consistent style, documenting complex logic, and relevant references
- Full testing coverage (Jest unit tests)
- Performance optimization (memoization, loops)
- Responsive design patterns
- Component scalability and maintainability
- Proper TypeScript types and interfaces usage
- Component, prop, and storybook documentation
Highlight any deviations from these standards.
Files:
packages/core/webpack/src/plugins/MoveFilesIntoDistFolderPlugin.tspackages/core/webpack/src/config/base.tspackages/core/webpack/src/utils/helpers.tspackages/core/webpack/src/rules/common.tspackages/core/webpack/src/plugins/dtsBundleGeneratorPlugin.tspackages/core/webpack/src/config/development.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/icon-creation.mdc)
Exported icon component should be PascalCase + 'Icon' (e.g.,
ShoppingCartIcon).
Files:
packages/core/webpack/src/plugins/MoveFilesIntoDistFolderPlugin.tspackages/core/webpack/src/config/base.tspackages/core/webpack/src/utils/helpers.tspackages/core/webpack/src/rules/common.tspackages/core/webpack/src/plugins/dtsBundleGeneratorPlugin.tspackages/core/webpack/src/config/development.ts
**/package.json
📄 CodeRabbit inference engine (.cursor/rules/package-json.mdc)
**/package.json: NEVER bump manually the version of the package.json file. It should be done automatically by the CI/CD pipeline. Only track in the specific CHANGELOG.md file the changes.
The 'name' key in package.json should be the name of the package, prefixed with @nimbus-ds/ (e.g., @nimbus-ds/skeleton).
The 'version' key in package.json: Initial version of a new package must be 0.0.0.
The 'files' key in package.json should list the files to be published to npm and must include: dist, README.md, and CHANGELOG.md.
The 'dependencies' key in package.json should only include runtime dependencies and must include all such dependencies. Do not include development or build-time dependencies here.
The 'devDependencies' key in package.json should only include development or build-time dependencies and must include all such dependencies.
The 'peerDependencies' key in package.json should only include runtime dependencies expected to be installed by the consumer.
The 'scripts' key in package.json should only include build, clean, and version scripts.
The 'homepage' key in package.json must be "https://nimbus.nuvemshop.com.br/documentation".
The 'repository' key in package.json must be of type "git" and have the URL "git+https://github.com/TiendaNube/nimbus-design-system.git".
The 'bugs' key in package.json must be "https://github.com/TiendaNube/nimbus-design-system/issues".
The 'license' key in package.json must be "MIT".
The 'main' key in package.json must be "dist/index.js".
The 'sideEffects' key in package.json must be false (boolean value).
Files:
package.json
⚙️ CodeRabbit configuration file
Verify version updates follow SemVer: major for breaking changes, minor for new features, patch for bug fixes. Ensure dependencies are properly versioned and peer dependencies are correctly specified.
Files:
package.json
🧬 Code graph analysis (2)
.scripts/setup-foundations.js (1)
.scripts/dev-setup.js (2)
require(10-10)require(11-11)
.scripts/dev-setup.js (1)
.scripts/setup-foundations.js (1)
require(10-10)
⏰ Context from checks skipped due to timeout of 30000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: pipeline-quality
- GitHub Check: Analyze SonarCloud
🔇 Additional comments (9)
packages/core/webpack/src/config/base.ts (1)
60-62: Verify monorepo workspace package resolution (packages/core/webpack/src/config/base.ts:60-62)
Disablingsymlinksin webpack can prevent it from following your workspace symlinks (e.g.@nimbus-ds/styles,@nimbus-ds/tokens). Confirm that your local packages still resolve correctly (via existing symlinks or an alias/tsconfig-paths setup).packages/core/webpack/src/plugins/dtsBundleGeneratorPlugin.ts (1)
22-27: Good implementation of CPU-aware concurrency limitsThe dynamic calculation of
maxConcurrentProcessesbased on available CPUs (75% utilization, bounded between 2-8) is a solid approach that prevents system overload while maintaining reasonable parallelism.packages/core/webpack/src/plugins/MoveFilesIntoDistFolderPlugin.ts (1)
66-78: Excellent resilience improvement with Promise.allSettledSwitching from
Promise.alltoPromise.allSettledprevents a single file copy failure from aborting the entire operation. The error handling appropriately distinguishes between missing files (ENOENT) and actual errors, logging warnings for the latter.packages/core/webpack/src/config/development.ts (1)
31-42: Well-structured filesystem cache configurationThe cache configuration is comprehensive and well-thought-out:
- Using
__filenameas a build dependency ensures cache invalidation on config changes- 7-day maxAge is reasonable for development
- Gzip compression balances size vs speed effectively
- Dynamic naming based on NODE_ENV prevents cache conflicts
package.json (2)
39-39: Good addition: explicit foundations setup entry point.Makes the flow clearer for CI/local prep.
42-42: LGTM: route start:dev through the orchestrator.Consistent with docs and the new setup flow.
.scripts/setup-foundations.js (1)
1-1: Shebang is correct and enables direct execution.No issues.
turbo.json (2)
12-15: Verify build:components outputs match actual layout.Pattern
packages/react/src/*/dist/**is unusual; components may live underatomic/andcomposite/per workspaces. Confirm paths to ensure cache hits.
46-53: Global dependency tracking looks good.These cover typical config invalidation points.
| packagesToBuild.forEach((pkg) => { | ||
| console.log(`⚙️ Building ${pkg.name} (${pkg.description})...`); | ||
| try { | ||
| execSync(pkg.buildCommand, { stdio: "inherit", cwd: process.cwd() }); | ||
| console.log(`✅ ${pkg.name} built successfully\n`); | ||
| } catch (error) { | ||
| console.error(`❌ Failed to build ${pkg.name}:`, error.message); | ||
| process.exit(1); | ||
| } | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Build failures should be more informative
When a build fails, only the error message is logged. Consider preserving and displaying the full error output to help developers diagnose issues.
try {
execSync(pkg.buildCommand, { stdio: "inherit", cwd: process.cwd() });
console.log(`✅ ${pkg.name} built successfully\n`);
} catch (error) {
- console.error(`❌ Failed to build ${pkg.name}:`, error.message);
+ console.error(`❌ Failed to build ${pkg.name}:`);
+ console.error(` Command: ${pkg.buildCommand}`);
+ console.error(` Error: ${error.message}`);
+ if (error.stdout) console.error(` Output: ${error.stdout.toString()}`);
process.exit(1);
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| packagesToBuild.forEach((pkg) => { | |
| console.log(`⚙️ Building ${pkg.name} (${pkg.description})...`); | |
| try { | |
| execSync(pkg.buildCommand, { stdio: "inherit", cwd: process.cwd() }); | |
| console.log(`✅ ${pkg.name} built successfully\n`); | |
| } catch (error) { | |
| console.error(`❌ Failed to build ${pkg.name}:`, error.message); | |
| process.exit(1); | |
| } | |
| }); | |
| packagesToBuild.forEach((pkg) => { | |
| console.log(`⚙️ Building ${pkg.name} (${pkg.description})...`); | |
| try { | |
| execSync(pkg.buildCommand, { stdio: "inherit", cwd: process.cwd() }); | |
| console.log(`✅ ${pkg.name} built successfully\n`); | |
| } catch (error) { | |
| console.error(`❌ Failed to build ${pkg.name}:`); | |
| console.error(` Command: ${pkg.buildCommand}`); | |
| console.error(` Error: ${error.message}`); | |
| if (error.stdout) console.error(` Output: ${error.stdout.toString()}`); | |
| process.exit(1); | |
| } | |
| }); |
🤖 Prompt for AI Agents
In .scripts/dev-setup.js around lines 51 to 60, the catch block only logs
error.message which loses command output; modify the catch to log the full
failure details by printing error.stdout and error.stderr (if present) and
fallback to error.stack or the entire error.toString(), e.g. capture and
console.error the stdout/stderr buffers (convert to string) and the stack, so
maintain process.exit(1) after logging the detailed output.
| function startStorybook() { | ||
| console.log("🚀 Starting Storybook development server...\n"); | ||
| try { | ||
| execSync("storybook dev -p 6006", { stdio: "inherit", cwd: process.cwd() }); |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Hardcoded Storybook command limits flexibility
The Storybook command is hardcoded with specific options. Consider making this configurable via environment variables or package.json scripts.
- execSync("storybook dev -p 6006", { stdio: "inherit", cwd: process.cwd() });
+ const storybookPort = process.env.STORYBOOK_PORT || "6006";
+ const storybookCmd = process.env.STORYBOOK_CMD || `storybook dev -p ${storybookPort}`;
+ execSync(storybookCmd, { stdio: "inherit", cwd: process.cwd() });📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| execSync("storybook dev -p 6006", { stdio: "inherit", cwd: process.cwd() }); | |
| // Allow overriding the Storybook port and full command via environment variables | |
| const storybookPort = process.env.STORYBOOK_PORT || "6006"; | |
| const storybookCmd = process.env.STORYBOOK_CMD || `storybook dev -p ${storybookPort}`; | |
| execSync(storybookCmd, { stdio: "inherit", cwd: process.cwd() }); |
🤖 Prompt for AI Agents
In .scripts/dev-setup.js around line 71 the Storybook start command is hardcoded
as "storybook dev -p 6006" which reduces flexibility; modify the script to read
the command and options from environment variables (e.g., STORYBOOK_CMD or
STORYBOOK_PORT) or from package.json scripts and fall back to the current
default, then use those values when calling execSync so callers can override the
command/port without editing the file.
| const { checkAndBuildFoundationalPackages } = require("./dev-setup"); | ||
|
|
||
| console.log("🏗️ Setting up Nimbus Design System foundational packages...\n"); | ||
|
|
||
| checkAndBuildFoundationalPackages(); | ||
|
|
||
| console.log("✨ Foundational packages setup complete!"); | ||
| console.log('💡 Run "yarn start:dev" to start the development server.'); |
There was a problem hiding this comment.
Fail fast with clear errors (wrap call, set exit code).
Current script logs success regardless of failures in the invoked function.
Apply this diff:
-const { checkAndBuildFoundationalPackages } = require("./dev-setup");
+const { checkAndBuildFoundationalPackages } = require("./dev-setup");
-console.log("🏗️ Setting up Nimbus Design System foundational packages...\n");
-
-checkAndBuildFoundationalPackages();
-
-console.log("✨ Foundational packages setup complete!");
-console.log('💡 Run "yarn start:dev" to start the development server.');
+console.log("🏗️ Setting up Nimbus Design System foundational packages...\n");
+try {
+ checkAndBuildFoundationalPackages();
+ console.log("✨ Foundational packages setup complete!");
+ console.log('💡 Run "yarn start:dev" to start the development server.');
+} catch (err) {
+ console.error("❌ Foundations setup failed.\n", err?.stderr?.toString?.() || err?.message || err);
+ process.exitCode = 1;
+}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const { checkAndBuildFoundationalPackages } = require("./dev-setup"); | |
| console.log("🏗️ Setting up Nimbus Design System foundational packages...\n"); | |
| checkAndBuildFoundationalPackages(); | |
| console.log("✨ Foundational packages setup complete!"); | |
| console.log('💡 Run "yarn start:dev" to start the development server.'); | |
| const { checkAndBuildFoundationalPackages } = require("./dev-setup"); | |
| console.log("🏗️ Setting up Nimbus Design System foundational packages...\n"); | |
| try { | |
| checkAndBuildFoundationalPackages(); | |
| console.log("✨ Foundational packages setup complete!"); | |
| console.log('💡 Run "yarn start:dev" to start the development server.'); | |
| } catch (err) { | |
| console.error( | |
| "❌ Foundations setup failed.\n", | |
| err?.stderr?.toString?.() || err?.message || err | |
| ); | |
| process.exitCode = 1; | |
| } |
🤖 Prompt for AI Agents
In .scripts/setup-foundations.js around lines 10 to 17, the script currently
calls checkAndBuildFoundationalPackages() and always prints a success message
even if that call fails; wrap the invocation in a try/catch (await if the
function returns a Promise), move the success console.logs into the try block,
and in the catch block log the error with a clear message and set
process.exitCode = 1 (or call process.exit(1)) so the process fails fast on
errors.
| ## Quick Start (New Contributors) | ||
|
|
||
| For new contributors or fresh clones, simply run: | ||
|
|
||
| ```bash | ||
| yarn start:dev | ||
| ``` |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Call out required Node/Yarn versions upfront.
Helps avoid environment flakiness for new contributors.
Add right after “Quick Start”:
+> Prereqs
+> - Node 14.17–16.x (per package.json engines)
+> - Yarn 3.2+📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ## Quick Start (New Contributors) | |
| For new contributors or fresh clones, simply run: | |
| ```bash | |
| yarn start:dev | |
| ``` | |
| ## Quick Start (New Contributors) | |
| > Prereqs | |
| > - Node 14.17–16.x (per package.json engines) | |
| > - Yarn 3.2+ | |
| For new contributors or fresh clones, simply run: | |
🤖 Prompt for AI Agents
In docs/DEVELOPMENT_SETUP.md around lines 5 to 11, add an explicit note
immediately after the "Quick Start" heading that states the required Node and
Yarn versions (e.g., "Requires Node >= X.Y.Z and Yarn >= A.B.C") and any
recommended NVM or installation guidance; ensure the versions are accurate for
the project, format it as a short single-line callout or bullet directly under
the header, and keep it concise so new contributors see version requirements
before running yarn start:dev.
| ### `yarn start:dev` | ||
|
|
||
| **Recommended for development** - Intelligent setup that builds dependencies as needed and starts Storybook. | ||
|
|
||
| ### `yarn setup:foundations` | ||
|
|
||
| **Build foundational packages only** - Useful for CI/CD or when you just want to ensure dependencies are built without starting the dev server. | ||
|
|
||
| ### `yarn storybook` | ||
|
|
||
| **Direct Storybook start** - Only use this if you're sure all foundational packages are already built. |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Mention the single canonical dev command; de-emphasize direct Storybook.
Keeps folks on the supported path and avoids missing prebuilds.
Apply this tweak:
-### `yarn storybook`
-
-**Direct Storybook start** - Only use this if you're sure all foundational packages are already built.
+### `yarn storybook` (optional)
+
+Only if foundations are built (prefer `yarn start:dev`).📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### `yarn start:dev` | |
| **Recommended for development** - Intelligent setup that builds dependencies as needed and starts Storybook. | |
| ### `yarn setup:foundations` | |
| **Build foundational packages only** - Useful for CI/CD or when you just want to ensure dependencies are built without starting the dev server. | |
| ### `yarn storybook` | |
| **Direct Storybook start** - Only use this if you're sure all foundational packages are already built. | |
| ### `yarn start:dev` | |
| **Recommended for development** - Intelligent setup that builds dependencies as needed and starts Storybook. | |
| ### `yarn setup:foundations` | |
| **Build foundational packages only** - Useful for CI/CD or when you just want to ensure dependencies are built without starting the dev server. | |
| ### `yarn storybook` (optional) | |
| Only if foundations are built (prefer `yarn start:dev`). |
🤖 Prompt for AI Agents
In docs/DEVELOPMENT_SETUP.md around lines 21 to 31, update the text to present a
single canonical development command (yarn start:dev) as the recommended
default, reword the yarn setup:foundations description to note it is for
CI/explicit prebuilds, and de-emphasize yarn storybook by adding a clear caution
that it should only be used when foundational packages are already built (or
after running setup:foundations or start:dev) so contributors follow the
supported path and avoid missing prebuilds.
| options: { | ||
| // Enable type checking in a separate process | ||
| transpileOnly: true, | ||
| compilerOptions: { | ||
| // Skip type checking | ||
| isolatedModules: true, | ||
| // Improve module resolution speed | ||
| moduleResolution: "node", | ||
| // Use incremental compilation | ||
| incremental: true, | ||
| }, | ||
| }, |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
transpileOnly disables all type checking - ensure alternative validation exists
Setting transpileOnly: true completely bypasses TypeScript type checking during builds, which could allow type errors to slip into production. While this significantly speeds up development builds, ensure that:
- Type checking runs in CI/CD pipelines
- Pre-commit hooks validate types
- IDE/editor integration provides real-time type feedback
🏁 Script executed:
#!/bin/bash
# Check if type checking is configured elsewhere
echo "Checking for TypeScript type checking in package.json scripts..."
fd -e json -x grep -l "tsc" {} \; | head -10
echo -e "\nChecking for type checking in CI workflows..."
fd -e yml -e yaml -p ".github" -x grep -l "tsc\|typecheck\|type-check" {} \; 2>/dev/null
echo -e "\nChecking for pre-commit hooks..."
if [ -f ".husky/pre-commit" ]; then
cat .husky/pre-commit
fi
echo -e "\nChecking turbo.json for typecheck targets..."
if [ -f "turbo.json" ]; then
cat turbo.json | jq '.pipeline | keys[] | select(contains("type") or contains("check"))'
fiLength of output: 668
🏁 Script executed:
#!/bin/bash
set -e
echo "=== Listing CI configuration directories ==="
fd .github/workflows -t f || echo "No .github/workflows directory"
fd .circleci -t f || echo "No .circleci directory"
echo -e "\n=== Root YAML files ==="
ls *.yml *.yaml 2>/dev/null || echo "No root-level YAML files"
echo -e "\n=== Root package.json scripts ==="
jq '.scripts' package.json
echo -e "\n=== Root package.json lint-staged config ==="
jq '.["lint-staged"]' package.json || echo "No lint-staged config in package.json"
echo -e "\n=== Husky pre-commit hook ==="
if [ -f ".husky/pre-commit" ]; then
cat .husky/pre-commit
else
echo "No .husky/pre-commit file"
fi
echo -e "\n=== turbo.json pipeline keys and commands ==="
jq '.pipeline' turbo.json
echo -e "\n=== Looking for types:check script in package.json ==="
jq '.scripts["types:check"]' package.json || echo "No types:check script found"Length of output: 4071
Enforce Type Checking Outside Webpack
Transpiling with transpileOnly: true skips all TS checks—although you have a types:check script, there’s no automation invoking it:
- CI: no
.github/workflowsor other CI config runsyarn types:check - Pre-push: no
.husky/pre-pushhook (only a pre-commit calling lint-staged) - lint-staged: no config found, so pre-commit won’t catch type errors
Add or confirm automated yarn types:check runs in your CI/CD pipeline, a Husky pre-push hook, and/or lint-staged tasks to prevent slipped type errors.
🤖 Prompt for AI Agents
packages/core/webpack/src/rules/common.ts lines 12-23: currently ts-loader is
configured with transpileOnly: true which skips TypeScript type checks; ensure
type checking is enforced outside Webpack by adding automated runs of your type
check script (yarn types:check) — add a CI job in your GitHub Actions (or other
CI) workflow to run yarn types:check, add a Husky pre-push hook that runs yarn
types:check (or run it via lint-staged for changed files), and/or update
lint-staged to include a type-check task so type errors cannot be slipped
through commits or CI.
| // Skip type checking | ||
| isolatedModules: true, |
There was a problem hiding this comment.
Comment contradicts the configuration
The comment states "Skip type checking" but isolatedModules: true doesn't skip type checking - it ensures each file can be transpiled independently. This is a requirement for transpileOnly mode, not a performance optimization.
Update the comment to accurately describe the setting:
- // Skip type checking
+ // Ensure each file can be transpiled independently (required for transpileOnly)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // Skip type checking | |
| isolatedModules: true, | |
| // Ensure each file can be transpiled independently (required for transpileOnly) | |
| isolatedModules: true, |
🤖 Prompt for AI Agents
In packages/core/webpack/src/rules/common.ts around lines 16-17, the existing
comment "Skip type checking" is incorrect for the setting isolatedModules: true;
update the comment to accurately describe that isolatedModules ensures each file
can be transpiled independently (a requirement for transpileOnly mode) and does
not itself skip type checking or act as a performance optimization.
| // Process each component folder in parallel for better performance | ||
| allComponents.forEach((componentPath) => { |
There was a problem hiding this comment.
Comment misleads: forEach is sequential, not parallel
The comment states "Process each component folder in parallel for better performance", but the implementation uses forEach which executes synchronously. This creates a false expectation about the code's behavior.
Either update the comment to reflect the sequential nature:
- // Process each component folder in parallel for better performance
+ // Process each component folderOr implement actual parallel processing if performance is a concern:
- // Process each component folder in parallel for better performance
- allComponents.forEach((componentPath) => {
+ // Process each component folder in parallel for better performance
+ await Promise.all(allComponents.map(async (componentPath) => {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // Process each component folder in parallel for better performance | |
| allComponents.forEach((componentPath) => { | |
| // Process each component folder | |
| allComponents.forEach((componentPath) => { |
🤖 Prompt for AI Agents
In packages/core/webpack/src/utils/helpers.ts around lines 42 to 43, the inline
comment claims "Process each component folder in parallel for better
performance" but the code uses allComponents.forEach which runs synchronously;
either update the comment to accurately state it's sequential, or change the
implementation to true parallel processing by mapping allComponents to an array
of promises (e.g., allComponents.map(componentPath =>
processComponent(componentPath))) and awaiting them with Promise.all, and ensure
proper error handling/propagation for the Promise.all result.
| const dtsCommand = `node --max-old-space-size=1024 ${rootDir}/node_modules/.bin/dts-bundle-generator -o ./dist/${componentName}/index.d.ts ${entryFile} ${extraCommands.join( | ||
| "" | ||
| )}`; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Node memory flag may be insufficient for large component libraries
The 1024MB heap size limit might be too restrictive for projects with many components or complex type definitions. Consider making this configurable or using a higher default.
Consider parameterizing the memory allocation:
- const dtsCommand = `node --max-old-space-size=1024 ${rootDir}/node_modules/.bin/dts-bundle-generator -o ./dist/${componentName}/index.d.ts ${entryFile} ${extraCommands.join(
+ const memorySize = process.env.DTS_MEMORY_SIZE || '2048';
+ const dtsCommand = `node --max-old-space-size=${memorySize} ${rootDir}/node_modules/.bin/dts-bundle-generator -o ./dist/${componentName}/index.d.ts ${entryFile} ${extraCommands.join(📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const dtsCommand = `node --max-old-space-size=1024 ${rootDir}/node_modules/.bin/dts-bundle-generator -o ./dist/${componentName}/index.d.ts ${entryFile} ${extraCommands.join( | |
| "" | |
| )}`; | |
| // Parameterize Node heap size for dts-bundle-generator | |
| const memorySize = process.env.DTS_MEMORY_SIZE || '2048'; | |
| const dtsCommand = `node --max-old-space-size=${memorySize} ${rootDir}/node_modules/.bin/dts-bundle-generator -o ./dist/${componentName}/index.d.ts ${entryFile} ${extraCommands.join( | |
| "" | |
| )}`; |
🤖 Prompt for AI Agents
In packages/core/webpack/src/utils/helpers.ts around lines 75 to 77, the
hardcoded Node heap flag (--max-old-space-size=1024) is too small for large
component libraries; make the memory allocation configurable by introducing a
parameter (or environment variable) for maxOldSpaceSize with a sensible larger
default (e.g., 4096), update the function signature to accept this option (or
read process.env.DTS_MEMORY_MB), validate/coerce to a number, and use that
variable in the dtsCommand string instead of the hardcoded 1024 so callers or CI
can tune memory without changing code.
| "start:dev": { | ||
| "dependsOn": ["build:tokens", "build:icons"], | ||
| "cache": false, | ||
| "persistent": true | ||
| }, |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Avoid double work: start:dev dependsOn vs dev-setup’s auto-build.
Right now both Turbo and the Node orchestrator ensure tokens/icons. Decide on a single source of truth to prevent redundant builds and divergent behavior.
Options:
- Keep dev-setup as orchestrator; drop
dependsOnhere. - Or rely on Turbo (
turbo run …) for start:dev and remove foundations logic from dev-setup.
Would you like a PR-ready patch for either path?
🤖 Prompt for AI Agents
turbo.json lines 32-36: current "start:dev" lists "dependsOn":
["build:tokens","build:icons"] which duplicates dev-setup’s auto-build; remove
the dependsOn property from the "start:dev" task so dev-setup remains the single
orchestrator for token/icon builds (i.e., delete the dependsOn entry and its
array), leaving any dev-setup logic unchanged; update docs/README if present to
note that dev-setup handles dev build steps.
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #344 +/- ##
=======================================
Coverage 99.37% 99.37%
=======================================
Files 360 360
Lines 2722 2726 +4
Branches 464 466 +2
=======================================
+ Hits 2705 2709 +4
Misses 16 16
Partials 1 1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
2 participants
Type
Changes proposed ✔️
Summary by CodeRabbit