Detecting a file type is pretty easy, it's all about knowing the File Signatures aka "magic numbers"! of the file.
Magic number are bytes within a file used to identify the format of the file; generally a short sequence of bytes (most are 2-4 bytes long) placed at the beginning of the file;
Normally on CLI one would use file command to determine file type. For example:
123
$ file meow.ogg
Ogg data, Vorbis audio, stereo, 44100 Hz, ~64000 bps, created by: Xiph.Org libVorbis I (1.1.0 RC1)
But would not it be fun to have a simple module that could read buffer as well as Buffer/Uint8Array ?
Well, here it is file-type detects the file type of a Buffer/Uint8Array!
P.R are welcome to that project and /me contributed audio-type to it.
So the logic behind is to read the required bytes using read-chunk and check for the required bytes, for example have a look at is-ogg.
The project is nicely aligned with the Unix Philosophy of doing one thing and doing it in the best way, each of the file types are broken down in the individual modules like:
$ grunt
Running "copy:html"(copy) task
Copied 1 file
Running "useminPrepare:html"(useminPrepare) task
Going through index.html to update the config
Looking for build script HTML comment blocks
Configuration is now:
concat:
{ generated:
{ files:
[{ dest: '.tmp/concat/assets/css/style.min.css',
src: ['assets/css/style.css']},
{ dest: '.tmp/concat/assets/js/optimized.js',
src: ['assets/js/foo.js', 'assets/js/bar.js']}]}} uglify:
{ generated:
{ files:
[{ dest: 'dist/assets/js/optimized.js',
src: ['.tmp/concat/assets/js/optimized.js']}]}} cssmin:
{ generated:
{ files:
[{ dest: 'dist/assets/css/style.min.css',
src: ['.tmp/concat/assets/css/style.min.css']}]}}Running "concat:generated"(concat) task
File ".tmp/concat/assets/css/style.min.css" created.
File ".tmp/concat/assets/js/optimized.js" created.
Running "uglify:generated"(uglify) task
File dist/assets/js/optimized.js created: 75 B → 58 B
Running "cssmin:generated"(cssmin) task
File dist/assets/css/style.min.css created: 48 B → 39 B
Running "usemin:html"(usemin) task
Processing as HTML - dist/index.html
Update the HTML to reference our concat/min/revved script files
Update the HTML with the new css filenames
Update the HTML with the new img filenames
Update the HTML with data-main tags
Update the HTML with data-* tags
Update the HTML with background imgs, case there is some inline style
Update the HTML with anchors images
Update the HTML with reference in input
Done, without errors.
"adds to package.json in current working directory, and creates if one is not found" is IMO conceptually simpler than the current situation.
Currently, npm install --save adds the dependency to the nearest package.json, searching up the directory tree. I doubt this is used very often, and it likely leads to more dependencies accidentally being added to the wrong package.json than the correct package.json.
npm also uses the realdir when handling symlinks, so if you're calling npm install --save from inside a symlinked dir, it'll find and add the dep the package.json in the parent real directory, rather than the symlinked one, so you now also need to worry about whether the directory you're in is a symlink or not. Maybe this feature is useful, maybe it's complicated.
The suggestion of calling npm init on missing package.json makes a lot of sense to me if we simplified the install logic to always just look in cwd.
Changing this behaviour could break a few builds, and there's also some consistency with the "find nearest package.json" logic across other npm commands, so it'd likely need to be changed there as well.
atom editor the editor that GitHub is building the text editor we've always wanted is at a very early state and has some great potential, luckily got an invite from to paw at and it and did a silly plugin for it as well which just plays around with some text converting colors to RGB:
Lately I wrote a Yeoman generator to create packages from atom editor. You can paw at the source of generator-atom and install it npm install generator-atom
[generator-atom]$ mkdir atom-plugin &&cd$_[generator-atom]$ yo atom
_-----_
| |
|--(o)--| .--------------------------.
`---------´ | Welcome to Yeoman, |
( _´U`_ ) | ladies and gentlemen! |
/___A___\ '__________________________' | ~ |
__'.___.'__
´ ` |° ´ Y `You're using the fantastic Atom generator.[?] What would like name your atom package? atom-plugin[?] Descirbe your package in one-line: My awesome atom package![?] What license would apply for this package? MIT[?] What's your github username? hemanth
[?] Are you using any grammars? yes
[?] Are you using keymaps? yes
[?] Are you adding menus? yes
[?] Are you writing any snippets? yes
[?] Are you doing some stylesheets? yes
create lib/atom-plugin.coffee
create grammars/grammar.cson
create keymaps/keymap.cson
create stylesheets/style.css
create menus/application-menu.cson
create menus/context-menu.cson
create snippets/language.cson
create spec/atom-plugin_test.coffee
create spec/fixtures/atom-plugin_fixture.coffee
create .jshintrc
create .gitignore
create .travis.yml
create README.md
create package.json
create index.coffee
I'm all done. Running npm install for you to install the required dependencies. If this fails, try running the command yourself.
[generator-atom]$ tree
.
├── README.md
├── grammars
│ └── grammar.cson
├── index.coffee
├── keymaps
│ └── keymap.cson
├── lib
│ └── atom-plugin.coffee
├── menus
│ ├── application-menu.cson
│ └── context-menu.cson
├── package.json
├── snippets
│ └── language.cson
├── spec
│ ├── atom-plugin_test.coffee
│ └── fixtures
│ └── atom-plugin_fixture.coffee
└── stylesheets
└── style.css
8 directories, 12 files
You may not need all of the directories, indeed based on your need. Each of those file will have minimal boilerplate code that would help you get started.
The index.coffee includes the file in the lib dir and it looks like:
{"name":"atom-plugin","main":"./lib/atom-plugin","version":"0.0.0","description":"My awesome atom package!","license":"MIT","private":true,"repository":"https://github.com/hemanth/atom-plugin","engines":{"atom":">0.61.0"},"dependencies":{}}
If you notice the version is 0.0.0 and modifying the code as per the need, you could do a apm publish minor to publish the package, giving the fact that the repo is published in Github.
gif FTW?
Yeoman as always been at our service to make life easier, hope this generator helps you to create atom packages with ease!
Further, it would be useful if you could read creating atom package an official documentation and their API.
There are few node modules out there for getting random free ports, but there is a easier way:
123456
varhttp=require('http');varserver=http.createServer();server.listen(0,IPv4);server.on('listening',function(){console.log('Server is running on: '+IPv4+':'+server.address().port);})
The trick is all about server.listen(0,IPv4) this will cause the server to listen on a random port unless in a cluster where each worker will receive the same "random" port each time they do a listen(0) i.e the port is random for the first time and there after it's predictable.
Well, there might be more better ways of doing this, but this was a quick hack I need to make for something I was working on.