Make package.json export wildcard files too #110
Conversation
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
This is needed to allow users to import parts of this package and not then entire server
mattpodwysocki
added a commit
that referenced
this pull request
Feb 9, 2026
This PR provides an alternative to #110's wildcard export approach by implementing explicit, well-documented subpath exports that give users direct access to Mapbox MCP components. ## Changes ### Package Exports (via tshy) - `@mapbox/mcp-server/tools` - Tool classes and pre-configured instances - `@mapbox/mcp-server/resources` - Resource classes and instances - `@mapbox/mcp-server/prompts` - Prompt classes and instances - `@mapbox/mcp-server/utils` - HTTP pipeline utilities All exports support both ESM and CommonJS via tshy dual builds. ### New Files - `src/tools/index.ts` - Barrel export for tools with clean instance names - `src/resources/index.ts` - Barrel export for resources - `src/prompts/index.ts` - Barrel export for prompts - `src/utils/index.ts` - Barrel export for HTTP utilities - `docs/importing-tools.md` - Comprehensive usage guide - `examples/import-example.ts` - Working code examples - `test/exports.test.ts` - Test suite validating all exports - `tsconfig.examples.json` - TypeScript config for examples ### Updated Files - `package.json` - Added tshy exports config, updated lint/format scripts - `tsconfig.json` - Added examples reference - `README.md` - Added link to importing guide - `CLAUDE.md` - Documented package exports ### Usage Examples Simple - pre-configured instances: ```typescript import { directions, searchAndGeocode } from '@mapbox/mcp-server/tools'; ``` Advanced - custom tool instances: ```typescript import { DirectionsTool } from '@mapbox/mcp-server/tools'; import { httpRequest } from '@mapbox/mcp-server/utils'; const tool = new DirectionsTool({ httpRequest }); ``` Expert - custom HTTP pipeline: ```typescript import { HttpPipeline, UserAgentPolicy } from '@mapbox/mcp-server/utils'; const pipeline = new HttpPipeline(); pipeline.usePolicy(new UserAgentPolicy('MyApp/1.0')); ``` ## Benefits Over Wildcard Approach 1. **Explicit API surface** - Only exports intended public APIs 2. **Better discoverability** - Clear, documented entry points 3. **Type safety** - Full TypeScript support for all exports 4. **Tree-shaking friendly** - Bundlers can optimize better 5. **Future-proof** - Easy to evolve without breaking changes ## Testing - All 611 existing tests pass - New test suite validates all subpath exports - Examples included in lint/format/type checking - Documentation with working examples Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
mattpodwysocki
added a commit
that referenced
this pull request
Feb 9, 2026
This PR provides an alternative to #110's wildcard export approach by implementing explicit, well-documented subpath exports that give users direct access to Mapbox MCP components. ## Changes ### Package Exports (via tshy) - `@mapbox/mcp-server/tools` - Tool classes and pre-configured instances - `@mapbox/mcp-server/resources` - Resource classes and instances - `@mapbox/mcp-server/prompts` - Prompt classes and instances - `@mapbox/mcp-server/utils` - HTTP pipeline utilities All exports support both ESM and CommonJS via tshy dual builds. ### New Files - `src/tools/index.ts` - Barrel export for tools with clean instance names - `src/resources/index.ts` - Barrel export for resources - `src/prompts/index.ts` - Barrel export for prompts - `src/utils/index.ts` - Barrel export for HTTP utilities - `docs/importing-tools.md` - Comprehensive usage guide - `examples/import-example.ts` - Working code examples - `test/exports.test.ts` - Test suite validating all exports - `tsconfig.examples.json` - TypeScript config for examples ### Updated Files - `package.json` - Added tshy exports config, updated lint/format scripts - `tsconfig.json` - Added examples reference - `README.md` - Added link to importing guide - `CLAUDE.md` - Documented package exports ### Usage Examples Simple - pre-configured instances: ```typescript import { directions, searchAndGeocode } from '@mapbox/mcp-server/tools'; ``` Advanced - custom tool instances: ```typescript import { DirectionsTool } from '@mapbox/mcp-server/tools'; import { httpRequest } from '@mapbox/mcp-server/utils'; const tool = new DirectionsTool({ httpRequest }); ``` Expert - custom HTTP pipeline: ```typescript import { HttpPipeline, UserAgentPolicy } from '@mapbox/mcp-server/utils'; const pipeline = new HttpPipeline(); pipeline.usePolicy(new UserAgentPolicy('MyApp/1.0')); ``` ## Benefits Over Wildcard Approach 1. **Explicit API surface** - Only exports intended public APIs 2. **Better discoverability** - Clear, documented entry points 3. **Type safety** - Full TypeScript support for all exports 4. **Tree-shaking friendly** - Bundlers can optimize better 5. **Future-proof** - Easy to evolve without breaking changes ## Testing - All 611 existing tests pass - New test suite validates all subpath exports - Examples included in lint/format/type checking - Documentation with working examples Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Contributor
|
Hey @vincent-lecrubier-skydio, thanks for opening this PR! Your use case of importing parts of the package without the entire server is definitely valuable. Instead of merging the wildcard export ( What's Available NowYou can now import exactly what you need: // Get the tools registry functions you mentioned
import { getCoreTools } from '@mapbox/mcp-server/tools';
import { httpRequest } from '@mapbox/mcp-server/utils';
// Or import specific tools directly
import { directions, searchAndGeocode } from '@mapbox/mcp-server/tools';
// Or import tool classes for custom instantiation
import { DirectionsTool } from '@mapbox/mcp-server/tools';
import { HttpPipeline, UserAgentPolicy } from '@mapbox/mcp-server/utils';Why Not Wildcard?The wildcard approach ("./": "./") would expose our entire internal structure, making it
Benefits of PR #111
Does This Work for Your Use Case?Could you take a look at PR #111 and let me know if the exposed APIs work for your internal MCP |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Description
This is needed to allow users to import parts of this package and not then entire server
In my case, I want to expose Mapbox MCP internally on my own MCP server, so I don't need the server, but I need
import { getCoreTools } from "@mapbox/mcp-server/dist/esm/tools/toolRegistry.js";This PR allows me to do that. Currently I patch the MCP package.json manually.
Testing
It works and doesn't break anything
Checklist
Additional Notes