Font Awesome v7 support

[piotr-sobczyk]

Is your feature request related to a problem? Please describe.
I've upgraded my fontawesome packages to v7, e.g.:

"@fortawesome/fontawesome-svg-core": "7.0.0",
"@fortawesome/pro-regular-svg-icons": "7.0.0",
"@fortawesome/pro-solid-svg-icons": "7.0.0",

The app still seems to be working but the package manager now reports peer dependency warning:

@fortawesome/fontawesome-svg-core is listed by your project with version 7.0.0 (pc980e), which doesn't satisfy what @fortawesome/react-native-fontawesome requests (^1.0.0 || ^6.0.0).

This makes me wonder if it's safe to use this package together with 7.0.0? Or should we wait a while with upgrading to 7.0.0 until this package is adjusted?

Describe the solution you'd like
Official support for @fortawesome/fontawesome-svg-core in version 7.0.0 without peer dependency warnings.

Describe alternatives you've considered
Not so much alternatives to consider. We can either bump to FA 7.0 or wait.

Additional context
None, the issue should be quite clear at this point.

[jasontxf]

I'm facing the same issue.

Considering whether I want to use Fontawesome now or switch to other libraries if this is not going to be solved anytime soon.

[hsource]

@mlwilkerson Just a heads up - I've migrated to using FontAwesome v7 despite it not being explicitly supported. Most icons look fine, but icons that overflow the boundaries of the SVG viewport get cut off, unlike on web where they overflow by default.

See FortAwesome/Font-Awesome#20781

My workaround has been to replace the icon with a scaled version that fits within the viewport, but that's not an ideal long-term solution.

I think one ideal solution could be:

1. Figure out how tall/wide the SVG actually is (including space outside the border) - this is hard though, as FontAwesome doesn't include any of the data for this in the package
2. Make it so that in convert, it applies negative margin and makes the itself larger so that it's still positioned correctly

[mlwilkerson]

@hsource Thanks for the report.

The challenge seems to be that (by default, at least?) the rendering environment where the standard FA7 icons are being used--i.e. React Native--does not support overflow. The overflow is a feature in FA7, not a bug. But yes, there are some environments that assume overflow is invalid (though it seems that they shouldn't be so restrictive).

So the usual workaround for overflow incompatible rendering environments is to use the "full" format SVGs, which do not overflow. An additional problem here is that the NPM packages like @fortawesome/pro-solid-svg-icons don't (yet?) include those full format SVGs.

But we do provide the full format SVGs elsewhere.

For example, if you were to download a kit, or the @fortawesome/fontawesome-pro NPM package, you'd see both the svgs and svgs-full subdirectories. The files in svgs-full are formatted such that their viewBoxes cover the full canvas and there is no overflow.

To my thinking, ideally, we'd provide full format SVG objects in these NPM packages (or alternate full format NPM packages). I think it might always be somewhat error prone to do format conversion within your app or build system. We've already done that internally and shipped the correct results. We just haven't done that in this specific distribution of SVGs (yet). Also, that format conversion would vary from one icon family to another. That's another key change in FA7--different families have different metrics for canvas size, icon grid size, and padding.

So while I also don't love the following idea, it's a possible workaround that eliminates guesswork about formatting:

Add a build step to your process that parses the SVGS under svgs-full in the @fortawesome/fontawesome-pro NPM. It would build an IconDefinition object from each .svg file, similar to this. You'd add each IconDefinition to the library or use them directly as values to props on the <FontAwesomeIcon> component.

Parsing the .svg files would be very straightforward. The width and height are obvious from the viewBox, and for monotone icons, there's only one <path>. One gotcha: for duotone icons, the path ordering matters, and may be counter-intuitive. Paths in the SVGs are written in descending order of their layer. So the secondary layer <path> appears before the primary layer <path>.

That's the workaround I'd recommend if you want to get into FA7 sooner and you find that the standard format SVG objects with overflow don't work in the React Native environment, and you want to use the full format SVGs instead.

[hsource]

@mlwilkerson Thanks! Yeah, that looks like a good generalization of the manual process we did for paperclip. We may do that if we notice other icons with similar issues!

[phazei]

Does this package have any maintainers?

@robmadole @jasonlundien @charles4221 ?

[hsource]

Here's a script I wrote to do the resizing. We don't want to use just the full icons because they often are way too small; what we want is to resize icons so they just exactly fill the space. Here's the flow:

File

async function run(logger: Logger) {
  const { package: iconPackage, icon: iconName } = args;

  // Construct the path to the icon file
  const packageRelativePath = path.join(
    'node_modules/@fortawesome',
    `free-${iconPackage}-svg-icons`,
  );
  const iconRelativePath = path.join(packageRelativePath, `${iconName}.js`);

  const inputIconPath = path.join(projectRoot, iconRelativePath);
  const outputIconPath = path.join(projectRoot, 'mobile', iconRelativePath);
  const outputIndexJSPath = path.join(
    projectRoot,
    'mobile',
    packageRelativePath,
    'index.js',
  );

  const {
    path: svgPathData,
    viewportWidth,
    viewportHeight,
  } = await readIconDataFromFile(inputIconPath);

  logger.info(`Icon dimensions: ${viewportWidth}x${viewportHeight}`);
  logger.info(`SVG path data length: ${svgPathData.length} characters`);

  // Call the library function to get the resized path
  const resizedPath = getResizedIconPathOrNull({
    path: svgPathData,
    viewportWidth,
    viewportHeight,
  });

  if (resizedPath === null) {
    logger.info('Icon does not need resizing (fits within bounding box)');
    return;
  }

  logger.info('Icon resized');

  // Write the modified path to the file
  const wasModified = await writeIconDataToFiles({
    filePath: outputIconPath,
    indexJSPath: outputIndexJSPath,
    iconName,
    newSVGPath: resizedPath,
  });

  if (wasModified) {
    logger.info(
      `Successfully resized and wrote icon to ${outputIconPath}. Run \`cd mobile && yarn patch-package @fortawesome/free-${iconPackage}-svg-icons\` to persist the changes.`,
    );
  } else {
    logger.info(`Icon file already contains the resized path`);
  }
}

Imports

import { promises as fs } from 'fs';
import { svgPathBbox } from 'svg-path-bbox';
import SVGPathCommander from 'svg-path-commander';

export interface IconSVGData {
  path: string;
  viewportWidth: number;
  viewportHeight: number;
  hasModifiedPath: boolean;
}

/**
 * Resizes an SVG path to fit within the declared bounding box if it extends
 * beyond it. Returns null if the icon fits within the bounding box without
 * resizing.
 */
export function getResizedIconPathOrNull({
  path,
  viewportWidth,
  viewportHeight,
}: {
  path: string;
  viewportWidth: number;
  viewportHeight: number;
}): string | null {
  // We use svgPathBbox since it seems more accurate than
  // `new SVGPathCommander(svgPath).getBBox();`
  const [minX, minY, maxX, maxY] = svgPathBbox(path);

  // Check if the icon extends beyond the declared bounding box
  const actualWidth = maxX - minX;
  const actualHeight = maxY - minY;

  // We allow icons to slightly extend beyond the declared bounding box to
  // account for rounding errors.
  const marginOfErrorPixels = 1;
  const needsResizing =
    maxX > viewportWidth + marginOfErrorPixels ||
    maxY > viewportHeight + marginOfErrorPixels ||
    minX < -marginOfErrorPixels ||
    minY < -marginOfErrorPixels;

  if (!needsResizing) {
    return null;
  }

  // Calculate the scale factor to fit the icon within the declared bounding box
  const scaleX = viewportWidth / actualWidth;
  const scaleY = viewportHeight / actualHeight;
  const scale = Math.min(scaleX, scaleY);

  // Calculate translation to center the icon within the bounding box
  const scaledWidth = actualWidth * scale;
  const scaledHeight = actualHeight * scale;
  const translateX = (viewportWidth - scaledWidth) / 2 - minX * scale;
  const translateY = (viewportHeight - scaledHeight) / 2 - minY * scale;

  // We round to 3 decimal places to keep the path short, since the original
  // paths have that decimal precision too
  const pathCommander = new SVGPathCommander(path, { round: 3 });
  // Apply transformation matrix: translate then scale
  const transformed = pathCommander
    .transform({
      translate: [translateX / scale, translateY / scale],
      scale,
    })
    .optimize();
  return transformed.toString();
}

/**
 * Reads icon data from a FontAwesome icon file like faStar.js at
 * node_modules/@fortawesome/free-solid-svg-icons/faStar.js
 *
 * See https://github.com/FortAwesome/Font-Awesome/blob/7.0.1/js-packages/%40fortawesome/free-solid-svg-icons/faStar.js
 * for the same file on Github.
 */
export async function readIconDataFromFile(
  filePath: string,
): Promise<IconSVGData> {
  const fileContents = await fs.readFile(filePath, 'utf8');

  const path = getFirstMatchOrThrow(
    fileContents,
    /var svgPathData = '([^']+)'/,
    'svgPathData',
  );
  const viewportWidth = parseInt(
    getFirstMatchOrThrow(fileContents, /var width = (\d+)/, 'width'),
    10,
  );
  const viewportHeight = parseInt(
    getFirstMatchOrThrow(fileContents, /var height = (\d+)/, 'height'),
    10,
  );

  return {
    path,
    viewportWidth,
    viewportHeight,
    hasModifiedPath: fileContents.includes(fileModifiedComment),
  };
}

function getFirstMatchOrThrow(
  fileContents: string,
  regex: RegExp,
  fieldName: string,
): string {
  const match = fileContents.match(regex);
  if (!match) {
    throw new Error(`Could not find ${fieldName} in file contents`);
  }
  return match[1];
}

/** We add this comment to indicate that we've resized the icon */
const fileModifiedComment = '// Modified by resizeOversizedFontAwesomeIcon.ts';

/**
 * Writes the modified icon path to a FontAwesome icon file and to the index.js
 * file.
 *
 * Returns true if the file was modified, false if it already contained the
 * modified content.
 */
export async function writeIconDataToFiles({
  filePath,
  indexJSPath,
  iconName,
  newSVGPath,
}: {
  /** Full path like `mobile/node_modules/@fortawesome/free-solid-svg-icons/faStar.js` */
  filePath: string;
  /** Full path like `mobile/node_modules/@fortawesome/free-solid-svg-icons/index.js` */
  indexJSPath: string;
  /** Name like `faStar` */
  iconName: string;
  newSVGPath: string;
}): Promise<boolean> {
  const fileContents = await fs.readFile(filePath, 'utf8');

  if (fileContents.includes(fileModifiedComment)) {
    return false;
  }

  await Promise.all([
    writeIconDataToMainFile({ filePath, fileContents, newSVGPath }),
    updateIndexJSFile({ indexJSPath, iconName, newSVGPath }),
  ]);
  return true;
}

/**
 * We create a subfunction to allow parallelizing the writes using Promise.all
 */
async function writeIconDataToMainFile({
  filePath,
  fileContents,
  newSVGPath,
}: {
  filePath: string;
  fileContents: string;
  newSVGPath: string;
}) {
  // We only need to replace 1 match
  // eslint-disable-next-line no-restricted-syntax
  const modifiedContents = fileContents.replace(
    /var svgPathData = '[^']+';/,
    `${fileModifiedComment}\nvar svgPathData = '${newSVGPath}';`,
  );

  await fs.writeFile(filePath, modifiedContents, 'utf8');
}

/**
 * When importing the icons on React Native, we actually import the index.js
 * file which contains a copy of all icon data.
 *
 * This function will write the modified icon data to the index.js file by
 *
 * 1. Finding the icon variable declaration for the iconName
 * 2. Finding the first `icon` array
 * 3. Replacing the last element of the array with the newSVGPath
 */
async function updateIndexJSFile({
  indexJSPath,
  iconName,
  newSVGPath,
}: {
  indexJSPath: string;
  iconName: string;
  newSVGPath: string;
}): Promise<boolean> {
  const fileContents = await fs.readFile(indexJSPath, 'utf8');

  // Split the file by the icon variable declaration
  const varDeclaration = `var ${iconName} = `;
  const parts = fileContents.split(varDeclaration);

  if (parts.length !== 2) {
    throw new Error(`Could not find unique icon ${iconName} in ${indexJSPath}`);
  }

  const [beforeIcon, afterVarDeclaration] = parts;

  // Matches a line like
  // `icon: [576, 512, ["dolly-box"], "f472", "M32 ..."]`
  const iconDataRegExp = /icon: ([^\n]+)/;
  const iconDataArrayStr = getFirstMatchOrThrow(
    afterVarDeclaration,
    iconDataRegExp,
    'icon line',
  );

  if (!iconDataArrayStr) {
    throw new Error(
      `Could not find icon array for ${iconName} in ${indexJSPath}`,
    );
  }

  const iconDataArray = JSON.parse(iconDataArrayStr);
  iconDataArray[iconDataArray.length - 1] = newSVGPath;

  const modifiedContents =
    beforeIcon +
    varDeclaration +
    afterVarDeclaration.replace(
      iconDataRegExp,
      `icon: ${JSON.stringify(iconDataArray)}`,
    );

  await fs.writeFile(indexJSPath, modifiedContents, 'utf8');
  return true;
}

[astrahov]

{
  "name": "@fortawesome/react-native-fontawesome",
  "version": "0.3.2",
  "license": "MIT",
  "peerDependencies": {
    "@fortawesome/fontawesome-svg-core": "~1 || ~6", <- Conflict Version with @fortawesome/fontawesome-svg-core@7.***
  },

[vjekob]

It would really be awesome if you would put a note on your React Native documentation page, telling us that you do not support version 7.1.0 in React Native.

But rather than investing (apparently) tons of money in new icon styles, you should invest a little time to make your core styles (those that probably convinced most of your customers to go with you, rather than any of the mounting number of competing icon providers) available.

You've increased the price of your subscriptions. Make us see what it is we are paying for.

[robmadole]

We do have a blurb at the top of our docs that mentions we don't support 7 yet.

I'll raise this up with our product lead so we can get this prioritized. Hopefully we can get some time to get this updated soon.

[sensibleworld]

Hey folks! As we look toward fully supporting v7 in our React Native implementation, I wanted to get some quick feedback. As @mlwilkerson mentioned above, v7 introduced a design change that gives certain icons a little more room to breathe. That means our icon canvas effectively expanded from 16px to 20px. In most environments (like our Kits), we allow icons to overflow that original grid so the visual size stays consistent. But in React Native, where SVG overflow isn’t supported, that extra space can get clipped — which obviously isn’t ideal.

To address this, we also offer “full” SVGs that include built-in padding and behave more like traditional icon sets. I’m curious why those would (or wouldn’t) work for folks. If they would solve things, I think we can find a straightforward way to support them in React Native.

Some of the feedback I’ve heard is that the full SVGs look too small. That’s true only if you do a 1-to-1 swap with your old v6 icon sizes. If you bump the size slightly (for example, using size="lg") they should visually match the cropped versions.

Would that adjustment get most of the way there for you?

[phazei]

@sensibleworld
In mobile it's much more work to get things pixel perfect, bumping to size 'lg' probably might not work work since it'd likely increase it too much, but we can adjust with some negative margins around a view containing the SVG I think. I'm not quite sure how we'd handle it till we go for it. But having the "fixedWidth" option that's available on web would help, is that what the 'full' SVG's would basically provide? If we could select between one or the other based on the props, that would be much easier. And unrelated but important is accessibility support.

[sensibleworld]

Thanks for the follow-up!

In mobile it's much more work to get things pixel perfect, bumping to size 'lg' probably might not work work since it'd likely increase it too much, but we can adjust with some negative margins around a view containing the SVG I think. I'm not quite sure how we'd handle it till we go for it.

If using a full SVG, bumping to lg would functionally make the icon glyph itself the same size as our standard SVGs. Super interesting to hear about negative margins, though. That might effectively do the same thing as what we're doing on the web.

But having the "fixedWidth" option that's available on web would help, is that what the 'full' SVG's would basically provide? If we could select between one or the other based on the props, that would be much easier.

Yes... the full SVGs are effectively a "fixedWidth" AND a "fixedHeight".

Our standard v7 SVGs (and Webfonts) are delivered at the same size and scaling as our v6 icons, but in both of those cases (using our built-in tooling) we have allowed overflow... which allows certainly items, like slashes, to extend beyond the core icon height while keeping the main glyph sizing consistent.

By default, our tooling now defaults to a fixed-width setting which keeps the widths of everything consistent. We've found that this is useful in the majority of cases where folks use icons. But if not needed, we now have an auto-width class you can apply to revert that.

With the FULL svgs, we've simply standardized everything to be square. This makes the viewbox/canvas larger than the v6 counterpart (and the standard v7 SVGs) but allows for much more consistency in implementation. We almost just shipped all of our v7 icons at these new sizes, but opted for the hybrid approach so that folks upgrading from v6 → v7 would have fewer headaches. This works in almost all situations, except cases (like React Native) where overflow isn't supported.

@phazei I'm curious if using the FULL SVGs with an added negative margin might work?

[phazei]

I think the negative margin might. That way it could still display the whole thing while not having it push a line higher than it already is. Though currently we're going through the hassle of react-native 0.76 and New Arch updates, so no clue how things might change with that.

[kutsan]

Any news on this?