search

scottdejonge / map-icons

An icon font for use with Google Maps API and Google Places API using SVG markers and icon labels
http://map-icons.com/
MIT License
1.05k stars 198 forks source link

Add package to npm #38

Open fvgs opened 8 years ago

fvgs commented 8 years ago

Could the package be added to the npm registry? Thanks!

scottdejonge commented 8 years ago

Looked into it. Not sure the best approach given the modular workflow with npm and using the font files form the packages. Open to suggestions.

fvgs commented 8 years ago

npm has been gradually getting better when it comes to front-end package management.

http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging

As someone currently trying out a new build process using webpack rather than Grunt, Browserify and all the rest of it, I think there is definitely a place for fonts, images, css, etc in an npm package. I haven't tried requiring fonts from a module. But worst case scenario, one would fall back to extracting the fonts from node_modules, which is no different than what I have to do now with bower.

I'm also moving away from using both bower and npm to just using npm. At this time, bower does not offer much over npm, and npm is the way of the future :)

scottdejonge commented 8 years ago

I agree with the npm worflow (and publish other packages to it) I guess I'm trying to work out the best solution given the multiple different dist files and types.

Can easily make the js Marker class extension a module to allow for require('map-icons') for browserify or Common.js workflows. It's the inclusion of the CSS and fonts that needs to be considered, using @import for node_modules/... is fragile at best in CSS and I want to avoid.

Also given the climate with icon fonts and accessibility (http://blog.cloudfour.com/seriously-dont-use-icon-fonts/) I would be tempted to move away from an icon font in this instance to a better way of handling icons. Most likely SVG paths for icons referenced by icon name. At that point having a json object of icons and paths that can be used in Google Maps would be far easier to deploy/package with the npm workflow, removing the fonts and CSS requirements.

But that is for a later version. Open to feedback.

fvgs commented 8 years ago

I agree the js part would be simple to adapt to a module. In the case of css, webpack actually allows for you to require() css and other assets straight into your javascript. So you would just need to require it into the entry script. What webpack actually ends up doing with it is injecting it into <style> sections in the DOM. For fonts, I'm not sure if the process is quite as elegant. But there seem to be ways to require() most types of assets directly into js, so I'm sure there's something out there for fonts. Though it may still require the fonts to be placed in a particular directory to be served.

Of course, this works all fine and well for webpack. But Browserify is still very popular and does not have the same capabilities. I don't think there is a general solution that will work for all build tools and platforms. But, imo the (bower + npm) model makes more sense for (Browserify + {Grunt, Gulp}) whereas the pure npm model makes more sense for webpack.

What we're really getting at is how best to setup front-end packages so they work for the different build systems. I'm of the opinion that front-end packages on npm should target build tools with capabilities like those of webpack. Whereas packages on bower should be less opinionated and more flexible.

That's an interesting thought about moving away from icon fonts. The benefits definitely seem clear. I think it would be a welcome improvement.