npm registries will close after August 1st: How to host at custom location?

[st-h]

Is your feature request related to a problem? Please describe.
For kickstarter backers the FA npm registries will close on 1st August 2020. This means, everyone who does not have an active FA pro subscription, will be unable to continue to build their projects after that date! I just confirmed this with the FA team via email.

Describe the solution you'd like
This addon should provide a way to load the necessary source files from other locations, so one is able to host them privately (in order to not violate the FA terms). Or probably we can figure out a way to host a copy on a private npm registry. At least we should have a way which will allow open source projects to continue to use this addon without having to get a yearly FA subscription.

[robmadole]

@st-h I just want to clarify and make sure we have the messaging correct.

You are talking about the Pro packages:

• @fortawesome/pro-solid-svg-icons
• @fortawesome/pro-regular-svg-icons
• @fortawesome/pro-light-svg-icons
• @fortawesome/pro-duotone-svg-icons

These packages are still available from NPM's public registry:

• @fortawesome/ember-fontawesome
• @fortawesome/fontawesome-svg-core
• @fortawesome/free-solid-svg-icons
• @fortawesome/free-regular-svg-icons
• @fortawesome/free-light-svg-icons
• @fortawesome/free-duotone-svg-icons

[st-h]

@robmadole Thanks for clarifying. I was asking this a few times, but never received a precise answer what would happen to the free packages. I was just told npm access is pro subscription only now and a build that uses the npm registry would no longer work after August, 1st.

Anyway, this is a very unfortunate situation for anyone who was an early FA5 backer, as npm is a very common and essential part of modern web development. I am not sure why you are trying to force those people to buy a subscription. Not that I wouldn't want to support FA6, or mind buying a subscription. However, I will certainly not support such practices.

Btw: is there any limitation about redistributing FA5 to FA5 owners? Private npm packages start at 7$/month. If there are a few users, we could easily host FA5 for a few cents/month. Just thinking aloud...

[robmadole]

I was asking this a few times, but never received a precise answer what would happen to the free packages.

Ah, gotcha. Yeah just pinged the team that we can probably be more specific about this.

I was just told npm access is pro subscription only now and a build that uses the npm registry would no longer work after August, 1st.

Yes, that is correct in terms of using the npm.fontawesome.com service. Font Awesome pays CloudSmith a monthly fee for the traffic and services they provide. And we get quite a bit of traffic so the costs are not trivial.

I am not sure why you are trying to force those people to buy a subscription.

It's just because this is a hard cost for us. The CloudSmith folks do a fantastic job and they charge for it. We have to re-coup those costs.

However, I will certainly not support such practices.

The practice of trying to force people to buy a subscription? We certainly aren't trying to force anyone to do anything. We are discounting the subscription for backers, working on tons of features beyond what were promised in the Kickstarter; our team actually thinks it's a pretty good deal. We could be wrong of course so I appreciate you chatting through it with me.

Btw: is there any limitation about redistributing FA5 to FA5 owners?

I think the tricky thing is that if someone was going to do this they'd be responsible for keeping our Pro license from being violated. Is that something you think people would be willing to do?

Private npm packages start at 7$/month. If there are a few users, we could easily host FA5 for a few cents/month. Just thinking aloud...

If we had a plan that just included hosted packages that was comparable to what a private npm package registry costs would that be viable?

[elgordino]

I was just browsing for a new icon on the FA website and came across this news. I have FA Pro from the kickstarter for the awesome set of additional icons, and I use the Pro NPM modules because they are the recommended install method for this add-on.

I appreciate the need to charge for pro services like support and hosting, you can't provide these forever, however I don't use any of the pro services other than the NPM modules and I am not keen to start paying for a subscription for hosting I could do myself.

The reason the pro icons are distributed via the CloudSmith CDN is because they need to be authenticated, this is costing FA money. Could FA provide the same package, but available for one-off download, rather than from an NPM source. The users can add the packages through either an artefact management service or just unpack locally in their pipelines. This would avoid the bandwidth bill for FA?

Alternatively the font awesome package can be downloaded as fontawesome-pro-5.13.0-web. It would be pretty easy to include that as an asset in a deployment pipeline. Could this add-on consume the files in that package and still perform the required tree shaking etc?

[robmadole]

@elgordino Could FA provide the same package, but available for one-off download, rather than from an NPM source.

We are exploring this idea right now. I think this is probably the best solution. We'd make the packages available from the download page directly.

[elgordino]

Thanks @robmadole that would be great.

[st-h]

@robmadole thank you for the explanation and please excuse if my comment should have sounded rude. I wasn't aware that you are forced to use a different way to host the pro npm packages. I am sure there are good reasons, why there isn't a less cost-intensive way. However, I hope it is understandable that taking away a fundamental building block of today's web development for the pro packages, while maintaining it for the free packages (which certainly have a way larger download volume), will not always be so well received. No question about CDN downloads etc, as that can easily create large bills - but I think no one is trying to make end users download via npm, so that likely should be different picture.

It would certainly have been a nice move to grant FA5 npm access to kickstarter backers. Most users probably will get the FA6 upgrade anyway. Personally, I would have favored the option to have the freedom to get a subscription when times are somewhat less troublesome on the financial side. Right now it is either: pay now or invest time and money to find a workaround. But, I have no clue how many pro packages have been sold, that are downloaded via npm and how large the volume of pro only downloads is. So I assume you have crunched the numbers and this is the only feasible way for your team to move on. As for now, I hardly have any time available to explore workarounds, so I'll get the subscription for now - and I'll keep my eyes open for alternatives, so we can switch when there is some time available.

I'll keep this issue open, as there seem to be more people that are interested in alternative download sources for this addon. Please feel free to close when it seems appropriate.

[robmadole]

However, I hope it is understandable that taking away a fundamental building block of today's web development for the pro packages, while maintaining it for the free packages (which certainly have a way larger download volume), will not always be so well received.

Yep, I totally understand. It's a fundamental piece of web development nowadays. We're continuing to chat through this and we want to make it as fair as possible. We don't want to piss off or hold anyone hostage. Our desire is that if people have the resources and see value in our service that they happily purchase.

No question about CDN downloads etc, as that can easily create large bills - but I think no one is trying to make end users download via npm, so that likely should be different picture.

Well, you'd be surprised. With large teams, continuous development/integration, and an increasingly large number of projects using NPM we have customers that are currently using more NPM bandwidth than their subscription pays for (as in we are losing money).

So I assume you have crunched the numbers and this is the only feasible way for your team to move on.

Yes we have. But we are continuing to listen as best we can to the folks like you who have supported us for a long time.

As for now, I hardly have any time available to explore workarounds, so I'll get the subscription for now - and I'll keep my eyes open for alternatives, so we can switch when there is some time available.

I think the decent thing we can do is make it as easy as we can to get packages. It's in our plans to make this less painful than it currently is.

[st-h]

Well, you'd be surprised. With large teams, continuous development/integration, and an increasingly large number of projects using NPM we have customers that are currently using more NPM bandwidth than their subscription pays for (as in we are losing money).

Wow. Sounds like some people could seriously speed up their build pipelines by using some caching 😂 but seriously, it's quite easy to run into those issues, as the fixed price mindset we usually have, can easily turn out problematic when the usage patterns vary a lot. As in big companies and independent individuals sharing the same subscription. Been there and I know it's often quite difficult to find a good compromise / different tiers which work for everyone. On the other hand, if those people using that much bandwidth would have to pay for what they use, they probably would bother to take an hour or two and would start to do something about it 🙈

[jrjohnson]

It is currently possible to import and pass icons directly in components from anywhere. NPM would be preferred, but it isn't strictly necessary.

Something like

import Component from '@glimmer/component';
import { pencil } from '../icons';

export default class UsesIconComponent extends Component {
  pencil = pencil;
}

<FaIcon @icon={{this.pencil}} />

Should be working today. I feel like the extra step is a bit of an annoyance, but it does unlock an additional feature which is dynamic subsetting and even asynchronous fetching of the assets.

If we settle on this as a good API maybe the FA team could create a code mod that would make moving to this syntax easy? Then apps could migrate in two steps:

1. New syntax with imports pulling the icons from NPM
2. A simple regex may be all that is needed to move to a locally hosted version of the assets

This would also make it possible to pull out something like 90% of the functionality of this addon making it much easier to maintain and work with. The cost is complexity of creating the imports put on every developer. RFC 496 hints at, but doesn't add a syntax for importing directly in a template which might make this a bit more ergonomic, but won't arrive in time for the Aug 1 deadline.

[elgordino]

As an update from my original comment. I decided, on reflection, that the subscription fee was worth the value we get from FontAwesome and have signed up. The 'sharp' icons looks pretty great too. Thanks.

[robmadole]

@jrjohnson I'm feeding your proposal into our FA v6 pipeline. Thanks for posting!