Skip to content

fix(sdk): remove @/ alias from tsconfig#165

Open
ilyamore88 wants to merge 3 commits into
mainfrom
fix/remove-alias-support-from-sdk
Open

fix(sdk): remove @/ alias from tsconfig#165
ilyamore88 wants to merge 3 commits into
mainfrom
fix/remove-alias-support-from-sdk

Conversation

@ilyamore88

Copy link
Copy Markdown
Member

Closes #164

I don't want to bring another dependency to the project, if we don't fully use aliases. I think aliases are not great for library like SDK, but it works fine in the playground app though.

@github-actions

github-actions Bot commented Jul 11, 2026

Copy link
Copy Markdown

Unit Tests

Package Coverage Delta
@editorjs/dom-adapters 86.95% 0% ⚪️
@editorjs/collaboration-manager 85.81% 0% ⚪️
@editorjs/ot-server 20% 0% ⚪️
@editorjs/core 89.55% 0% ⚪️

Mutation Tests

Package Mutation score Dashboard URL
@editorjs/dom-adapters No files to mutate found.
@editorjs/collaboration-manager No files to mutate found.
@editorjs/core No files to mutate found.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

Removes the @/ TypeScript path alias from the SDK build so emitted dist imports don’t rely on TS-only path mapping (addressing #164 / ts-jest consuming dist).

Changes:

  • Removed paths alias configuration from packages/sdk/tsconfig.json.
  • Rewrote SDK source imports to use relative paths / barrel exports instead of @/….
  • Adjusted SDK entity exports and some UI inline-toolbar code cleanup.

Reviewed changes

Copilot reviewed 14 out of 15 changed files in this pull request and generated 11 comments.

Show a summary per file
File Description
packages/ui/src/InlineToolbar/InlineToolbar.ts Removes an ESLint suppression around inline toolbar item mapping.
packages/sdk/tsconfig.json Drops paths mapping for @/* alias.
packages/sdk/src/tools/facades/BaseToolFacade.ts Updates imports away from @/ and adjusts entity imports/re-exports.
packages/sdk/src/tools/facades/BaseToolFacade.spec.ts Updates test imports away from @/.
packages/sdk/src/entities/InlineTool.ts Converts @/ type imports to relative imports.
packages/sdk/src/entities/index.ts Changes barrel exports to include runtime exports from BaseTool/BlockTool.
packages/sdk/src/entities/EventBus/events/core/ToolLoadedCoreEvent.ts Replaces @/tools/... import with relative tools import.
packages/sdk/src/entities/EventBus/events/core/SelectionChangedCoreEvent.ts Replaces @/tools import with relative tools import.
packages/sdk/src/entities/EditorjsPlugin.ts Replaces @/ imports with relative imports.
packages/sdk/src/entities/EditorjsAdapterPlugin.ts Replaces @/ imports with relative imports.
packages/sdk/src/entities/BlockTune.ts Replaces @/ imports with relative imports.
packages/sdk/src/entities/BlockToolAdapter.ts Replaces @/ imports with relative imports.
packages/sdk/src/entities/BlockTool.ts Replaces @/ imports with relative imports.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines 179 to 183
return [toolbarConfig]
.flat()
.map((item): PopoverItemParams[] => {
switch (item.type) {
case PopoverItemType.Html:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Verified both claims: removing the disable doesn't reintroduce no-unsafe-return (flagged as unused when re-added). Also checked the type concern — .flat() already infers MenuConfigItem[] correctly, same as an Array.isArray rewrite would. No type-safety loss, not necessary to change.

Comment on lines +7 to +13
import { ToolType, BaseToolOptionKey } from '../../entities';
import { type BlockTuneFacade } from './BlockTuneFacade.js';
import type {
BlockTool, BlockToolConstructor, InlineTool, InlineToolConstructor, BlockTuneConstructor,
ToolTypeToOptions
ToolTypeToOptions, ToolStaticOptions, BlockToolOptions, InlineToolOptions, BlockTuneOptions
} from '../../entities';
import type { ToolStaticOptions, BlockToolOptions, InlineToolOptions, BlockTuneOptions } from '../../entities/BaseTool.js';
import { BaseToolOptionKey } from '../../entities/BaseTool.js';
import type { EditorAPI } from '@/api';
import type { EditorAPI } from '../../api';
Comment on lines +4 to +11
import type { BlockToolConstructor, BlockToolData } from '../../entities';
import { BlockToolOptionKey, ToolType } from '../../entities';
import type { ToolOptions } from './BaseToolFacade.js';
import { UserToolOptions } from './BaseToolFacade.js';
import { BlockToolFacade } from './BlockToolFacade.js';
import type { InlineFragment } from '@editorjs/model-types';
import { BlockChildType, NODE_TYPE_HIDDEN_PROP } from '@editorjs/model-types';
import type { EditorAPI } from '@/api';
import type { EditorAPI } from '../../api';

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Same value-import issue as here. One correction: it doesn't actually break yarn testts-jest's resolver is CommonJS-like and masks it, so green tests aren't a safety signal here.

Comment on lines +5 to +8
import type { ToolType } from './EntityType.js';
import type { BaseToolConstructor, BaseToolOptions } from './BaseTool';
import type { EditorAPI } from '../api';
import type { MenuConfig } from './MenuConfig.js';
Comment on lines 8 to +11
import type { BlockToolAdapter } from './BlockToolAdapter.js';
import type { ToolType } from '@/entities/EntityType.js';
import type { BaseToolConstructor, BaseToolOptions } from '@/entities/BaseTool';
import type { EditorAPI } from '@/api';
import type { ToolType } from './EntityType.js';
import type { BaseToolConstructor, BaseToolOptions } from './BaseTool';
import type { EditorAPI } from '../api';
Comment on lines +1 to +4
import type { EventBus } from './EventBus/EventBus.js';
import type { CoreConfigValidated } from './Config.js';
import type { EditorAPI } from '../api';
import type { EntityType } from './EntityType.js';
Comment on lines +1 to +4
import type { EditorjsPlugin, EditorjsPluginConstructor } from './EditorjsPlugin';
import type { BlockId } from '@editorjs/model-types';
import type { PluginType } from '@/entities/EntityType';
import type { BlockToolAdapter } from '@/entities/BlockToolAdapter';
import type { PluginType } from './EntityType';
import type { BlockToolAdapter } from './BlockToolAdapter';
BlockChildType
} from '@editorjs/model-types';
import type { CoreConfig } from '@/entities/Config';
import type { CoreConfig } from './Config';
@@ -1,4 +1,4 @@
import type { ToolFacadeClass } from '@/tools/facades/index.js';
import type { ToolFacadeClass } from '../../../../tools';
import { CoreEventType } from './CoreEventType.js';
import type { InlineFragment, Index } from '@editorjs/model-types';
import type { InlineToolFacade } from '@/tools';
import type { InlineToolFacade } from '../../../../tools';

@Reversean Reversean left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

One more spot the alias cleanup missed: packages/sdk/jest.config.ts still has '^@/(.*)$': '<rootDir>/src/$1' in moduleNameMapper (this file isn't touched by the PR). It's dead now that nothing imports @/, but worth removing for a complete cleanup.

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.

[SDK] Typescript aliases in import paths are not resolved after compilation

4 participants