Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat: loadFromUrl supports Node.js environment #503

Merged
merged 17 commits into from
Nov 15, 2023

Conversation

antoineol
Copy link
Contributor

@antoineol antoineol commented Feb 12, 2022

Description

This solution provides a node implementation to fetch the font file from the URL, using standard http/https modules (to avoid adding a dependency like axios).

Btw the typing of load() does not include the third parameter that allows to use loadFromUrl. I don't know who is maintaining it.

Motivation and Context

loadFromUrl assumes it is run in the browser environment only, but I needed it in Node.js environment. I tried to polyfill XHR2, but the polyfill seems to have a bug: something hangs for 120 seconds. So I provide a nodejs implementation here.

How Has This Been Tested?

The function loadFromUrl was tested with code like:

  const url = 'https://github.com/Templarian/MaterialDesign-Webfont/blob/master/fonts/materialdesignicons-webfont.ttf?raw=true';
  const res = await new Promise<ArrayBufferLike>((resolve, reject) => {
    loadFromUrl(url, (error, response) => {
      if (error) reject(error);
      else resolve(response);
    });
  });

  console.log(new TextDecoder().decode(res));

And I tested a larger workflow with something like load(url, undefined, { isUrl: true }), ensuring it returns the font with the data I expected.

Environment: node. No impact noticed on the rest of the library. All unit tests are still passing (with just 2 warnings that were already there).

Screenshots (if appropriate):

N/A

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Counted as new feature, but I'm tempted to say it's a bug, since it uses the existing API in node, which is supposed to be a supported environment. :)

Checklist:

  • I did npm run test and all tests passed green (including code styling checks). => 2 warnings for code styling that were already there when I forked the master.
  • I have added tests to cover my changes.
  • My change requires a change to the documentation.
  • I have updated the README accordingly.
  • I have read the CONTRIBUTING document.

@yne
Copy link
Contributor

yne commented Apr 19, 2022

I just learned that Node 18 natively support fetch()

@Connum
Copy link
Contributor

Connum commented Feb 4, 2023

I just made a PR on the fork to add a test for this.

Edit: at some point we might want to switch over to fetch completely, but I'm fine with fixing it like that for now, as Node 16 (LTS) has just reached EOL about 3 months ago. Browser-wise, all evergreen browsers support fetch now, and I'm not 100% sure, but I guess this should be polyfilled for older browsers during build anyway.

@ILOVEPIE maybe we need some kind of roadmap to keep track of things like this?

@Connum Connum linked an issue Feb 4, 2023 that may be closed by this pull request
@ILOVEPIE
Copy link
Contributor

ILOVEPIE commented Feb 4, 2023

@ILOVEPIE maybe we need some kind of roadmap to keep track of things like this?
@Connum milestones were being used before, we can setup new ones, also we should start using the discussions tab too.

@ILOVEPIE ILOVEPIE added this to the Release 2.0.0 milestone Feb 5, 2023
@ILOVEPIE ILOVEPIE requested a review from Connum February 5, 2023 19:59
@ILOVEPIE
Copy link
Contributor

ILOVEPIE commented Feb 5, 2023

@Connum we should get this reviewed and merged, once the tests are in.

@Connum
Copy link
Contributor

Connum commented Feb 5, 2023

Alternatively, instead of waiting for @antoineol, we could merge this PR and add the test with a separate PR.

@ILOVEPIE
Copy link
Contributor

ILOVEPIE commented Feb 6, 2023

@Connum I think it's bests to keep tests in the same PR. I'm not too fond of the idea of committing something to master without testing it.

@Connum
Copy link
Contributor

Connum commented Feb 10, 2023

Pinging @antoineol

If we don't hear back, we should make a new PR from this PR merged with the test I added

@Connum Connum self-assigned this Feb 15, 2023
Copy link
Contributor

@Connum Connum left a comment

Choose a reason for hiding this comment

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

I finally managed to merge the test myself with the help of gh CLI.

@Connum Connum requested a review from ILOVEPIE February 17, 2023 09:54
@Connum Connum removed their assignment Feb 17, 2023
@Connum
Copy link
Contributor

Connum commented Feb 17, 2023

Just adapted the test because it didn't pass anymore due to the changes in the names object

test/opentypeSpec.js Outdated Show resolved Hide resolved
Copy link
Contributor

@ILOVEPIE ILOVEPIE left a comment

Choose a reason for hiding this comment

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

We should avoid redundant checks in the code.

test/opentypeSpec.js Outdated Show resolved Hide resolved
@Connum Connum requested a review from ILOVEPIE February 17, 2023 21:25
@Connum Connum dismissed ILOVEPIE’s stale review November 15, 2023 15:26

no longer applies

@Connum
Copy link
Contributor

Connum commented Nov 15, 2023

added http and https as externals to make this run with esbuild, and fixed the test that relied on a no longer existing font file.

@Connum Connum merged commit a285517 into opentypejs:master Nov 15, 2023
1 check passed
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.

loadFromUrl does not support Node.js environment
4 participants