FIX @W-21462752@ - Fix parser not configured when both JS and LWC base configs d…#431
Merged
aruntyagiTutu merged 4 commits intodevfrom Mar 9, 2026
Conversation
…isabled Issue: When users set both disable_javascript_base_config: true AND disable_lwc_base_config: true, ESLint failed to parse .js files with decorators with error: 'Unexpected character @' Root Cause: The createBaseConfigArray() method had no fallback case when both base configs were disabled. This caused no parser to be configured at all, making ESLint default to Espree which cannot parse decorators. Solution: Added createMinimalJavascriptParserConfig() method that configures ONLY the parser (without base rules) when both configs are disabled: - Uses Babel parser for .js files (supports decorators + JSX) - Uses Espree parser for .jsx/.mjs/.cjs only (performance optimization) Changes: - base-config.ts: Added fallback case and createMinimalJavascriptParserConfig() - parser-selection.test.ts: Added 6 comprehensive tests covering all edge cases - package.json: Bumped version to 0.40.2-SNAPSHOT Test Coverage: - Both JS and LWC disabled with .js files - Both disabled with only .jsx files - Both disabled with .mjs/.cjs files - Both disabled with mixed .js and .jsx files - All three configs disabled (JS, LWC, React) - No JavaScript extensions present All 282 tests passing with 99.83% code coverage.
…fig is true Extended the previous fix to also handle TypeScript files. When users set disable_typescript_base_config: true, TypeScript files failed to parse with error: 'Unexpected token :' (from type annotations). Root Cause: Same as JavaScript bug - when the TypeScript base config is disabled, no TypeScript parser was configured, causing ESLint to use a parser that cannot handle TypeScript syntax. Solution: Added createMinimalTypescriptParserConfig() method that configures ONLY the TypeScript parser (without base rules or projectService) when the base config is disabled. Note: The minimal TypeScript config intentionally omits projectService to allow parsing TypeScript files that aren't part of a tsconfig.json project. This means type-aware rules won't work, but syntax parsing (decorators, type annotations) will function correctly. Changes: - base-config.ts: Added TypeScript fallback case and createMinimalTypescriptParserConfig() - parser-selection.test.ts: Added 2 tests for TypeScript with base config disabled - Test data: Added workspaceWithTsDecorators and workspaceWithTsx test fixtures Test Coverage: - TypeScript files with decorators when disable_typescript_base_config: true - TSX files with JSX when disable_typescript_base_config: true All 284 tests passing with 99.83% code coverage.
…ious flag combinations Added 5 integration tests to verify that React, LWC, and TypeScript files parse correctly and can be analyzed with different combinations of disable flags. Tests verify: 1. React JSX parsing when all base configs disabled 2. LWC decorator parsing when only JS base config disabled (LWC enabled) 3. Mixed React and LWC files when JS base disabled 4. All base configs disabled but parsing still works 5. TypeScript parsing when TS base config disabled Test Data Created: - workspaceWithReactViolations/ComponentWithViolations.jsx - React with unused vars - workspaceWithLwcViolations/lwcComponentWithViolations.js - LWC with @api reassignment - workspaceWithTsViolations/tsFileWithViolations.ts - TypeScript with debugger These tests ensure that our parser selection logic works correctly across all supported languages and frameworks, regardless of which base configs are enabled or disabled. Results: - All 289 tests passing - 99.83% code coverage maintained
…ategy Applied PR review feedback to enhance code documentation and test clarity: 1. Added comprehensive overview comment at top of BaseConfigFactory class - Documents parser selection strategy for JS, TS, React, LWC, and SLDS - Explains when minimal parser fallback activates - Clarifies key design principle: disabling base configs disables RULES, not parsing 2. Enhanced TypeScript minimal parser config documentation - Added "IMPORTANT LIMITATION" section explaining type-aware rules won't work - Documented trade-offs: can parse TS syntax but not run type-aware rules - Clear guidance on when users should enable TS base config 3. Updated integration test names to explicitly mention "minimal parser fallback" - Makes it clearer what mechanism is being tested - Distinguishes between LWC parser usage vs minimal fallback - More descriptive test names improve maintainability Changes are non-breaking and documentation-only. All 289 tests still passing with 99.83% coverage.
nikhil-mittal-165
approved these changes
Mar 9, 2026
namrata111f
reviewed
Mar 9, 2026
| } else if (this.engineConfig.file_extensions.typescript.length > 0) { | ||
| // When TS base config is disabled, we still need to configure a parser for TypeScript files | ||
| // to avoid ESLint falling back to a parser that can't handle TypeScript syntax | ||
| configArray.push(...this.createMinimalTypescriptParserConfig()); |
Contributor
There was a problem hiding this comment.
Do we need to introduce new function here? Can we directly use useTsBaseConfig? Or maybe combine this.useTsBaseConfig() with or of this.engineConfig.file_extensions.typescript.length > 0.
namrata111f
reviewed
Mar 9, 2026
Comment on lines
+256
to
+270
| // .js files might have LWC decorators - use Babel parser with decorator support | ||
| const lwcConfig = validateAndGetRawLwcConfigArray()[0]; | ||
| const babelParser = lwcConfig.languageOptions?.parser; | ||
| const originalParserOptions = lwcConfig.languageOptions?.parserOptions as Linter.ParserOptions; | ||
| const originalBabelOptions = originalParserOptions.babelOptions || {}; | ||
|
|
||
| // Add @babel/preset-react to support JSX in React files alongside LWC files | ||
| const enhancedParserOptions = { | ||
| ...originalParserOptions, | ||
| babelOptions: { | ||
| ...originalBabelOptions, | ||
| configFile: false, | ||
| // Add React preset for JSX support (.jsx files and React in .js files) | ||
| presets: [...(originalBabelOptions.presets || []), require.resolve('@babel/preset-react')] | ||
| } |
Contributor
There was a problem hiding this comment.
Same here can we use the createJavascriptPlusLwcConfigArray and useJsBaseConfig instead here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue:
When users set both disable_javascript_base_config: true AND disable_lwc_base_config: true, ESLint failed to parse .js files with decorators with error: 'Unexpected character @'
Root Cause:
The createBaseConfigArray() method had no fallback case when both base configs were disabled. This caused no parser to be configured at all, making ESLint default to Espree which cannot parse decorators.
Solution:
Added createMinimalJavascriptParserConfig() method that configures ONLY the parser (without base rules) when both configs are disabled:
Changes:
Test Coverage:
All 282 tests passing with 99.83% code coverage.