Npm package about gameicons-font HOT 14 CLOSED

This repo is already updated nightly.

I do not have plans to publish it on npm since I don't really know the logistics behind that, nor do I really have a solid strategy to not just publish it nightly and instead do smart changes etc. I'll leave this open but I personally don't have interest at this time.

from gameicons-font.

Hi @seiyria, thanks for the quick response. I failed to check for this in the repo history 😅.

I'll leave some source material that could help here in case you change your mind in the future - It's quite easy:

How to publish Node.js packages with Travis CI and packagecloud

PS.: A good strategy could be checking their RSS feed and only then retrieving and updating your package to a new version. Since you are using Gulp and already run your CI nightly, this would be very straightforward.

from gameicons-font.

Yep, no problem. What I mean more specifically by "logistics" is that I have no idea how this should all be packaged or how users would consume it. Right now, it's a bunch of images.

from gameicons-font.

@seiyria A natural assumption for my use-case would be to use it as a css package like font-awesome - how are you using it?

from gameicons-font.

It depends. In one project I pull in the SVGs I want and then build them using a different tool.

In the past I have also used my filtering tool on a fork to build out exactly what I want.

For other projects, I use the hosted version as a lite CDN.

So, this is why I ask, there is no natural assumption for how this can or should be used. Especially with how different packages function. With bootstrap and old font awesome, you just include the CSS. Now, you have this mess. I imagine it's similar if you wanted to use it with first class support for react as well.

I'm more than happy to have whatever happen here, but I don't know what that will be. Even with an example like font awesome, it's still a bit nebulous. What exactly would you like, and are you willing to make it?

from gameicons-font.

So, this is why I ask, there is no natural assumption for how this can or should be used

@seiyria I guess what I was expecting is very inline with font-awesome and other icon-fonts usage, which normally is: pull in the CSS package with the class definitions and just use it.

With bootstrap and old font awesome, you just include the CSS. Now, you have this mess

You still can just include the CSS from the npm package if you want: Using a Package Manager.
The new approach just enables more componentization because of the wide variety of new icons - and it makes easy for bundlers to do tree-shaking.

Since I don't do SPAs anymore I guess this kind of usage is completely out of scope for me...
But I guess the simpler use-case would be just publishing it as CSS package with the webfonts. Also, to reduce fonts sizes you could generate separate fonts/ classes by tag.

from gameicons-font.

Yes, certainly it could just be that simple. However, the modern approaches are what I find the average user will be looking for, so a prospective solution would have to support them as well if possible.

I'm not sure what you mean by tag; I don't think there is anything of the sort presently available.

from gameicons-font.

While this is not particularly my use-case, I have to admit that could be useful. I think that the solution I gave lies in-between the two regarding effort and flexibility to use.

I'm not sure what you mean by tag; I don't think there is anything of the sort presently available.

I meant that you can use the website tags to group the icons and generate them individually to reduce the webfont size. You can see all the tags in here: https://game-icons.net/tags.html.
You can also see the tags for an individual icon by accessing the public directory with the same path you have after downloading the bundle: https://game-icons.net/1x1/{creator}/{icon}.html.

from gameicons-font.

To be honest, I'm not sure grouping them by tag holds any value for a user (outside of easy search on a website). Same with by author. I'm not particularly concerned with size (although if a user was I would hope they reach out in the future).

Anyhow, I definitely would accept a PR on this sort of thing! Seems right now the thing to do would be to build it and make sure it isn't built more often than it needs to be.

from gameicons-font.

To be honest, I'm not sure grouping them by tag holds any value for a user (outside of easy search on a website). Same with by author

Grouping it by tag would help reduce the size of the webfont if the user is not using the whole set of icons (much like the approach of 'requiring' components).

Currently, this repo's webfonts are ~1.33 MB - which is quite heavy to bundle in a web app. Compare that with font awesome's icons, which are around 90 KB - because they split the bundle using the same approach I'm talking about.

from gameicons-font.

Yes, size-wise, I understand that. Font awesome is a lot easier to do that sort of categorization with because those are meaningful categories, and they only have 3 of them (I just set it up myself the other day for a project).

With font awesome, you're likely going to be using multiple from the same set at least.

Compare this to the probably 100 tags on game icons, ranging from 10 to 100 or so icons per set. Additionally, you're likely not going to use too many icons from the same set. Personally, when I've used game icons, I always needed very specific icons and I never needed a whole tag of them. It's also a bit disingenuous to compare size in the way you are - game-icons has over double the icons in font awesome (in the free set). Yes, this still has a massive webfont (which I can't do much about) but these icons IIRC are way more detailed and have a larger base size. They're also not optimized for web font usage; this is something I have done out of necessity.

To this end, if people want modular builds of game icons, I recommend doing what I do and taking the icons you want and making a new web font out of them. I don't see there being a form of categorization in the same vein as font awesome that will be particularly effective for game icons.

from gameicons-font.

Yes, I agree that the tags do not represent groups of related icons to use like font awesome's. But I still think that it's better to have the option to import some icons you need other than everything 😁 (for componentization sake).

Additionally, you're likely not going to use too many icons from the same set. Personally, when I've used game icons, I always needed very specific icons and I never needed a whole tag of them

I can relate to that and it makes sense for some kind of games like the ones you have in your Github account, but I can think of some simpler games that could use standalone sets or even not use a great number of tag subsets.

Also, a note on the icon set sizes: I wasn't making a direct comparison though, was just illustrative of what it can be achieved by splitting the bundle 😄.

I think is good to mention that the GameIcons library is in constant expansion because of it's growing popularity, maybe a few months from now the average number of icons on sets could radically increase.

from gameicons-font.

Yes, I agree that the tags do not represent groups of related icons to use like font awesome's. But I still think that it's better to have the option to import some icons you need other than everything 😁 (for componentization sake).

Doing something simply to do it is not the right choice to make here. If there is no net gain (which it doesn't sound like there will be) then doing this is more overhead for no benefit.

Yes, I think it's reasonable to assume their icon set will expand (as I've seen whilst subscribed to their RSS feed) but more icon sets is not good in this case. I think there's potential for a solution here, but based on their existing tags is not the right one.

Either way, if you would like to submit a PR to make this build nightly and publish to npm (smartly, ie, not every night even if there is no update), I'd be ok to accept that. Anything else is outside the scope of this issue past this point.

from gameicons-font.

Doing something simply to do it is not the right choice to make here. If there is no net gain (which it doesn't sound like there will be) then doing this is more overhead for no benefit.

Well, then I failed to show the benefits I see in this approach - maybe I'm biased because this could be particularly useful in my case 😅.

Either way, if you would like to submit a PR to make this build nightly and publish to npm (smartly, ie, not every night even if there is no update), I'd be ok to accept that. Anything else is outside the scope of this issue past this point.

I've forked the project, but in IMHO a huge npm package by itself is not as useful. Since you pointed other changes are out of scope right now, I'm closing this issue. Thanks for your time!

from gameicons-font.