Better library support and better linting

[brunopagno]

Counterpart of opf/op-blocknote-hocuspocus#27

What are you trying to accomplish?

Making the library better support moduleResolution other than bundler

Additionally improve linting, so we don't forget to add extensions to files. This makes it better supported by node.

This simplifies importing this library in projects like https://github.com/opf/op-blocknote-hocuspocus

What approach did you choose and why?

• include file extensions on imports
• adjust tsconfig/package.json exports and linting rules

[Copilot]

Pull request overview

This pull request improves library support for different TypeScript module resolution strategies by adding explicit file extensions to all relative imports. It also enhances linting to enforce this convention going forward.

Changes:

• Added .ts and .tsx file extensions to all relative imports across the codebase
• Updated TypeScript configuration to better support bundler mode with explicit module/moduleResolution settings
• Added eslint-plugin-import to enforce import conventions
• Updated package.json exports to include wildcard pattern for subpath exports

Reviewed changes

Copilot reviewed 9 out of 10 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
tsconfig.lib.json	Added explicit module settings and updated include pattern to be more specific
package.json	Added eslint-plugin-import dependency and wildcard export pattern
package-lock.json	Updated dependencies including eslint-plugin-import and related transitive dependencies; version bump to 0.0.22
lib/services/openProjectApi.ts	Added .ts extension to openProjectTypes import
lib/services/colors.ts	Added .ts extensions to imports
lib/index.ts	Added .ts and .tsx extensions to imports
lib/hooks/useWorkPackageSearch.ts	Added .ts extension to openProjectApi import
lib/hooks/useWorkPackage.ts	Added .ts extension to openProjectApi import
lib/components/index.ts	Added .tsx extensions to component imports
eslint.config.js	Added eslint-plugin-import with extension rules for JS files

---

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

[Copilot]

The wildcard export pattern ./* with ./dist/*.d.ts and ./dist/*.js may not work as expected for module resolution. This pattern will match any subpath and try to map it directly to dist, but this is rarely the intended behavior for a library. Consider whether:

1. You want to export specific subpaths (e.g., "./services": { "types": "./dist/services/openProjectApi.d.ts", ... }), or
2. If this wildcard is intentional, ensure it correctly handles nested paths like op-blocknote-extensions/services/colors by ensuring the build outputs match this structure.

Suggested change

	},
	"./*": {
	"types": "./dist/*.d.ts",
	"import": "./dist/*.js"

[Copilot]

The tsconfig.lib.json specifies "moduleResolution": "bundler" which overrides the parent config. This is appropriate for library mode, but note that allowImportingTsExtensions from the parent tsconfig.app.json is inherited. Since this is a library being built for distribution, using moduleResolution: "bundler" with allowImportingTsExtensions will allow .ts extensions in imports but these extensions will be preserved in the generated .d.ts files. This might cause issues for consumers of this library who don't use bundler module resolution. Consider testing that the generated type declarations work correctly for consumers using other module resolution strategies.

Suggested change

	"moduleResolution": "bundler",
	"moduleResolution": "bundler",
	"allowImportingTsExtensions": false,

[brunopagno]

If we throw when trying to link work packages we break converting to Markdown, which thean breaks hocuspocus.

Instead of handing on the consumer, I felt like this makes more sense, and it still keeps security intact as we don't inject any invalid user input into the result