I built a wrapper of this font for React that uses the Material Design Icons font and wraps it in convenient components. Under the hood, it just uses the font from the CDN, so the usage was as always.
Now, it is pretty common to just inline the SVG icons into React apps, so I wrote a script that does this for your icons and I'd like to publish that as an npm package.
I have two questions:
Edit: Just read the Getting started guide which includes an HTML file with inlined SVGs for Polymer. So I'd think that it's okay to provide inline SVGs for React?
So, we'll be releasing a NPM/Bower repo shortly with just SVG files you can reference in a dependency.
The current licensing doesn't really allow this as it's only tailored for the webfont. We'll have to update the licensing etc when this repo is released (fun ๐).
I'm 90% sure these will be under MIT license (need to do some looking into this).
Lets leave this opened until we have this figured out. Like always make sure you're working with the https://materialdesignicons.com/design SVG files. The ones in the repo are not optimized or versioned (another reason why we're going to be creating a separate distribution).
That's great news, especially if they are going to be licensed under MIT! I'll wait with publishing my package then.
The thing is that I can't just reference the dependency but need to re-deploy them, but the MIT would allow this (btw. I'd like to deploy my package under MIT, too).
I'm currently working with these icons, but it would be great to have optimized icons. :+1:
I actually have the ability to create this repo already for v1.9.32
... question though. How should we format the directory?
Remember this is going to be a dependency eventually for the custom font builder. Should it just be a root repo with all [soon to be] 2k icons in SVG?
Want to make it as basic as possible, since I'm sure many other libraries will soon rely on it.
Ideal structure would be this imo:
root
โโ lib
โ โโ circle.svg
โโ README.md
Well, in the end, the format doesn't matter _that_ much. As long as there are files with names that represent the icon name (I convert the file name to PascalCaseFileNameIcon
, for example).
It would be nice to have a list of aliases, as js file.
Maybe like this:
root
โโ lib
โ โโ circle
โ โโ index.js (exports the list of aliases, see below)
โ โโ circle.svg
โโ README.md
That would be a lot of files, though. So maybe _one_ js file with a list of aliases would be better.
If we bundled the http://cdn.materialdesignicons.com/1.9.32/meta.json with dist, like we do on the webfont CDN would that be enough? Meta includes all the information one would needs to work with the files for various uses.
Naming would match the naming on the site (hyphenated arrow-right-circle.svg
style.
https://github.com/Templarian/MaterialDesign-SVG
Still need to add the NPM/Bower files and publish them. I might have to use the Apache 2.0 license, still looking into this.
Yes, the meta.json
is fine, I didn't know about that file. :+1: I'll update my scripts and wait for a license. Thank you very much for the fast response and your hard work on the icons!
@Templarian I would love to understand current licensing limitations... I came across this post after already publishing a CLI that creates <symbols>
from material icons: icosystem-cli (I assumed this was okay since your homepage allowed unrestricted downloads of the svgs...).
Should I take the this down till there's a proper license in place?
Also, I'd love to pull icons from github rather than https://materialdesignicons.com/design - I'm currently housing all of the SVG's in my repo (temporary solution).
FYI this project rocks ๐
@geoctrl Nah, you're fine. It's our fault we didn't have a nice solution before. I didn't really look how many others were using the SVG files and how they were using them. What ever license we pick it will allow everything you're doing.
We'll just obviously like you to reference (via NPM/bower/github) the SVG repo as a dependency so that users always have latest (realistically we do renames and tweaks to existing icons over time and can't expect 3rd parties to update right away no matter how dedicated they are).
The first goal of this project is foremost to get people to use the icons. ๐
What ever license we pick it will allow everything you're doing.
:+1:
We'll just obviously like you to reference (via NPM/bower/github) the SVG repo as a dependency so that users always have latest [...]
When re-packaging the SVGs (as React component or inside SVG <symbol>
s), the users won't get the latest icons even if we reference the upstream project as dependency, though. It would just make our lives much easier (npm upgrade
to get the latest SVGs, np minor
to update our packages).
That works too, yea forgot about those instances. Either way the tooling to build the symbols can use it as a dependency so if they need to generate them themselves. Just thinking long term this project will be around and I want the third party resources to still be usable if people depend on them.
Your dist would be more of a snapshot, will make sure everything like this is allowed.
๐
awesome - thanks ๐
@Templarian - let me know if you need help with anything (besides making icons). I do front-end things ๐
@Templarian Are there any news on the license yet? This would just fit perfectly in a project I'm currently working on. :sweat_smile:
@leMaik Conferences and changing jobs at the moment ๐ . Will try and spend some time this weekend to get this wrapped up. It's the next thing on my to do list.
Wohoo, looks like you have found a license! :tada: Thanks again for your work!
Yep, can't wait to see what people make! Eventually mdi-svg
will be the repo for the grunt-webfont
or similar webfont building tutorials.