feat: add npm provider to support locally installed packages

[rrroy5640]

Resolves #188

Description

This PR adds a new npm provider that allows Unifont to resolve fonts from locally installed npm packages (especially @fontsource packages) before attempting to fetch them from remote CDNs. This improves performance, reduces network requests, and provides better offline support.

Key Changes

• Added a new npm provider that scans for installed @fontsource packages in node_modules
• Implemented a mechanism to extract font information from local CSS files
• Added a preferLocal option to Unifont configuration, which prioritizes the npm provider when set to true
• Created comprehensive unit tests for the new provider
• Added integration tests to verify the provider works correctly with other providers
• Provided usage examples in the examples directory

Testing

The implementation includes:

• Unit tests for the npm provider functionality
• Integration tests that verify the provider works correctly in isolation and with other providers
• Manual testing with various font packages

Usage Example

import { createUnifont, providers } from 'unifont'

// Method 1: Only use local fonts
const unifont = await createUnifont([
  providers.npm()
])

// Method 2: Prioritize local fonts, fall back to remote sources
const unifont = await createUnifont(
  [
    providers.npm(),  // Auto-detect installed font packages
    providers.google(), // Fall back to Google Fonts if not found locally
  ],
  { preferLocal: true } // Prioritize local packages
)

// Method 3: Specify which packages to check
const unifont = await createUnifont([
  providers.npm({
    packages: ['@fontsource/roboto', '@fontsource/open-sans']
  })
])

Additional Notes

• The provider automatically scans for @fontsource packages if no packages are explicitly specified
• Font URLs are converted to file:// protocol for local access
• Metadata is added to indicate the font comes from npm and which package it comes from

[danielroe]

this looks amazing and I can't wait to get it merged!

a few comments.

[danielroe]

let's instead try to check the package.json of the workspace - we can use pkg-types for this. And ideally I think we can also support other common fonts like cal-sans, geist, etc.

[danielroe]

I'd like to remove the fontsource 'special-handling', if possible, and come up with a solution that works for fontsource but also conceivable supports auto-detection for other providers

[rrroy5640]

thank you for the feedback Daniel, I have just made the changes to support generic multiple font packages :)

[florian-lefebvre]

I think this provider shouldn't be only called npm, but still mention fontsource eg. providers.fontsourceNpm

[florian-lefebvre]

Ah sorry I missed this is supposed to work non fontsource packages too

[qwerzl]

I'm wondering if it's really necessary for us to explicitly support third-party packages like Geist. Perhaps a more scalable approach would be to expose an API like Next.js does and let packages integrate with us instead.

Support for Fontsource packages would be great though, given that they're already a well established and standardized system.

[rrroy5640]

I'm wondering if it's really necessary for us to explicitly support third-party packages like Geist. Perhaps a more scalable approach would be to expose an API like Next.js does and let packages integrate with us instead.

Support for Fontsource packages would be great though, given that they're already a well established and standardized system.

Yeah that seems more scalable in long term, do you reckon we keep basic support for Fontsource and expose API for other packages? This hybrid approach can potentially bring extra complexity though, I'm not very experienced with this yet, I would let the reviewers make the reviewers make the decision.