GithubHelp home page GithubHelp logo

rc's Introduction

rc

The non-configurable configuration loader for lazy people.

Usage

The only option is to pass rc the name of your app, and your default configuration.

var conf = require('rc')(appname, {
  //defaults go here.
  port: 2468,

  //defaults which are objects will be merged, not replaced
  views: {
    engine: 'jade'
  }
});

rc will return your configuration options merged with the defaults you specify. If you pass in a predefined defaults object, it will be mutated:

var conf = {};
require('rc')(appname, conf);

If rc finds any config files for your app, the returned config object will have a configs array containing their paths:

var appCfg = require('rc')(appname, conf);
appCfg.configs[0] // /etc/appnamerc
appCfg.configs[1] // /home/dominictarr/.config/appname
appCfg.config // same as appCfg.configs[appCfg.configs.length - 1]

Standards

Given your application name (appname), rc will look in all the obvious places for configuration.

  • command line arguments, parsed by minimist (e.g. --foo baz, also nested: --foo.bar=baz)
  • environment variables prefixed with ${appname}_
    • or use "__" to indicate nested properties
      (e.g. appname_foo__bar__baz => foo.bar.baz)
  • if you passed an option --config file then from that file
  • a local .${appname}rc or the first found looking in ./ ../ ../../ ../../../ etc.
  • $HOME/.${appname}rc
  • $HOME/.${appname}/config
  • $HOME/.config/${appname}
  • $HOME/.config/${appname}/config
  • /etc/${appname}rc
  • /etc/${appname}/config
  • the defaults object you passed in.

All configuration sources that were found will be flattened into one object, so that sources earlier in this list override later ones.

Configuration File Formats

Configuration files (e.g. .appnamerc) may be in either json or ini format. No file extension (.json or .ini) should be used. The example configurations below are equivalent:

Formatted as ini

; You can include comments in `ini` format if you want.

dependsOn=0.10.0


; `rc` has built-in support for ini sections, see?

[commands]
  www     = ./commands/www
  console = ./commands/repl


; You can even do nested sections

[generators.options]
  engine  = ejs

[generators.modules]
  new     = generate-new
  engine  = generate-backend

Formatted as json

{
  // You can even comment your JSON, if you want
  "dependsOn": "0.10.0",
  "commands": {
    "www": "./commands/www",
    "console": "./commands/repl"
  },
  "generators": {
    "options": {
      "engine": "ejs"
    },
    "modules": {
      "new": "generate-new",
      "backend": "generate-backend"
    }
  }
}

Comments are stripped from JSON config via strip-json-comments.

Since ini, and env variables do not have a standard for types, your application needs be prepared for strings.

To ensure that string representations of booleans and numbers are always converted into their proper types (especially useful if you intend to do strict === comparisons), consider using a module such as parse-strings-in-object to wrap the config object returned from rc.

Simple example demonstrating precedence

Assume you have an application like this (notice the hard-coded defaults passed to rc):

const conf = require('rc')('myapp', {
    port: 12345,
    mode: 'test'
});

console.log(JSON.stringify(conf, null, 2));

You also have a file config.json, with these contents:

{
  "port": 9000,
  "foo": "from config json",
  "something": "else"
}

And a file .myapprc in the same folder, with these contents:

{
  "port": "3001",
  "foo": "bar"
}

Here is the expected output from various commands:

node .

{
  "port": "3001",
  "mode": "test",
  "foo": "bar",
  "_": [],
  "configs": [
    "/Users/stephen/repos/conftest/.myapprc"
  ],
  "config": "/Users/stephen/repos/conftest/.myapprc"
}

Default mode from hard-coded object is retained, but port is overridden by .myapprc file (automatically found based on appname match), and foo is added.

node . --foo baz

{
  "port": "3001",
  "mode": "test",
  "foo": "baz",
  "_": [],
  "configs": [
    "/Users/stephen/repos/conftest/.myapprc"
  ],
  "config": "/Users/stephen/repos/conftest/.myapprc"
}

Same result as above but foo is overridden because command-line arguments take precedence over .myapprc file.

node . --foo barbar --config config.json

{
  "port": 9000,
  "mode": "test",
  "foo": "barbar",
  "something": "else",
  "_": [],
  "config": "config.json",
  "configs": [
    "/Users/stephen/repos/conftest/.myapprc",
    "config.json"
  ]
}

Now the port comes from the config.json file specified (overriding the value from .myapprc), and foo value is overriden by command-line despite also being specified in the config.json file.

Advanced Usage

Pass in your own argv

You may pass in your own argv as the third argument to rc. This is in case you want to use your own command-line opts parser.

require('rc')(appname, defaults, customArgvParser);

Pass in your own parser

If you have a special need to use a non-standard parser, you can do so by passing in the parser as the 4th argument. (leave the 3rd as null to get the default args parser)

require('rc')(appname, defaults, null, parser);

This may also be used to force a more strict format, such as strict, valid JSON only.

Note on Performance

rc is running fs.statSync-- so make sure you don't use it in a hot code path (e.g. a request handler)

License

Multi-licensed under the two-clause BSD License, MIT License, or Apache License, version 2.0

rc's People

Contributors

adjohnson916 avatar anselanza avatar anthonator avatar davglass avatar dbkaplun avatar dominictarr avatar eush77 avatar jcollado avatar jeremyruppel avatar kemitchell avatar ljharb avatar mikermcneil avatar nw avatar pdehaan avatar ralphtheninja avatar rschick avatar sam-github avatar tomc974 avatar tommytroylin avatar tonistiigi avatar trysound avatar vladtsf avatar ysangkok avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rc's Issues

filename/path examples

I'm trying to create an rc for use with node-inspector on Windows and not seeing the config take affect. On the off-chance, that it's that package, I've posted there also though I'm confident it's just me being slow in interpreting the README for this project and to that end I was hoping that this request and responses it gets will help others in the future or lead to content for the README that would have gotten through to the likes of me :)

That said, the way I interpret the README is as follows:

  • Assume my app is at c:\projects\my-app
  • Assume that in that folder a package.json exists that includes { "name": "my-app" }
  • Assume that my user folder is c:\users\myusername

I'm under the impression that any of the following locations would be valid for an rc file. Please let me know if the following demonstrates where I've gone wrong and how to correct it:

  • c:\projects\my-app\.$my-apprc
  • c:\projects\.$my-apprc
  • c:\users\myusername\.$my-apprc
  • c:\users\myusername\.$my-apprc
  • c:\users\myusername\.$my-app\config
  • c:\users\myusername\.config\.$my-app

expose the file(s) config was taken from.

When you pass in the --config option, the application will know the file
the config was loaded from. This could be useful for 1) updating config programatically, and 2) looking relative to the config file, i.e. for ssl keys.

it could be an array of file names in the override order. (first is local config, etc)

Empty config object in bower on ubuntu

When using the rc package in bower I expirience the following issue.

The lines: https://github.com/bower/bower/blob/master/lib/core/config.js#L39-l49
return an empty object:

config = {}

The defaults passed to rc:

{
  cache: '/home/vagrant/.bower/cache',
  links: '/home/vagrant/.bower/links',
  completion: '/home/vagrant/.bower/completion',
  git_template: '/home/vagrant/.bower/git_template',
  json: 'bower.json',
  endpoint: 'https://bower.herokuapp.com',
  directory: 'components',
  proxy: undefined,
  shorthand_resolver: 'git://github.com/{{{ endpoint }}}.git'
}

My system:

Linux elasticsearch.dev 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

My environment variables are:

MANPATH=/home/vagrant/.nvm/v0.11.2/share/man:
rvm_bin_path=/home/vagrant/.rvm/bin
TERM=xterm-256color
SHELL=/bin/bash
NVM_PATH=/home/vagrant/.nvm/v0.11.2/lib/node
OLDPWD=/home/vagrant/.nvm/v0.11.2/lib/node_modules/bower
LC_ALL=en_US.UTF-8
NVM_DIR=/home/vagrant/.nvm
USER=vagrant
rvm_path=/home/vagrant/.rvm
rvm_prefix=/home/vagrant
MAIL=/var/mail/vagrant
PATH=/home/vagrant/.nvm/v0.11.2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/opt/ruby/bin/:/home/vagrant/.rvm/bin
PWD=/home/vagrant/.nvm/v0.11.2/lib/node_modules/bower/lib
LANG=en_US.UTF-8
rvm_version=1.20.12 (stable)
SHLVL=1
HOME=/home/vagrant
LANGUAGE=en_US.UTF-8
LOGNAME=vagrant
LC_CTYPE=UTF-8
NVM_BIN=/home/vagrant/.nvm/v0.11.2/bin
JRUBY_OPTS=
RBXOPT=
_=/usr/bin/env
SSH_CLIENT=...
SSH_TTY=...
SSH_AUTH_SOCK=...
SSH_CONNECTION=...

minimist supports option aliases, can rc?

With minimist, I can do:

minimist(process.argv, {
  boolean: ['a', 'b'],
  alias: { c: 'a' },
  default: defaults
});

Using rc, minimist figures out the booleans for me, and I provide the defaults explicitly - but there's no way to specify aliases.

Parsing of package.name for organizations

Hi,

I have been starting to use organization packages from npmjs.

Most of my code are in the following format:

const packageJson = require('./package.json');
const config = rc(packageJson.name, {});

If I have the following in package.json:

  "name": "@someOrg/core",

I need to create the file .@someOrg/corerc which is not what I would expect. The following package would have created someOrg-core tarball from npm pack. Would it make sense to also have the same formula to find the rc file? I would prefer to create the file as .someOrg-corerc or even better .someOrg-core.rc.

Thanks,

Permit .json and .ini suffixes on config files

rc is awesome!

It's a tiny thing, but it would be great if the config file logic would permit .json and .ini extensions. In other words, looking for .${appname}rc, .${appname}rc.json or .${appname}rc.ini in all the usual places.

Definitely helps with triggering syntax highlighting in your editor of choice.

This idea was mentioned in #71, but since the scope of this feature request is far smaller in scope, I've opened it as a separate issue.

Version history?

Came here to see what changed between 0.6.0 and 1.0 and was disappointed that there is neither a history.md file, nor are there any git version tags. After looking through the commits it doesn't appear that there were any breaking changes, but I'd feel a lot more comfortable about upgrading if there was some kind of history prose.

Feature: parse YAML

Would be great if rc could parse YAML. YAML is a very common configuration language that is easier to read than JSON and more intuitive than INI. YAML is also a superset of JSON, so this feature would obviate the need for a special JSON parser. ๐Ÿ•

node 0.10 compatibility

I'm getting an error on node 0.10.x.
If I run the tests, it also fails.

 [email protected] test /Users/satazor/Work/misc/rc
> node test.js


path.js:360
        throw new TypeError('Arguments to path.join must be strings');
              ^
TypeError: Arguments to path.join must be strings
    at path.js:360:15
    at Array.filter (native)
    at exports.join (path.js:358:36)
    at Function.exports.json (/Users/satazor/Work/misc/rc/node_modules/config-chain/index.js:53:24)
    at module.exports (/Users/satazor/Work/misc/rc/index.js:28:8)
    at Object.<anonymous> (/Users/satazor/Work/misc/rc/test.js:7:27)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
npm ERR! Test failed.  See above for more details.
npm ERR! not ok code 0

If I console.log the arguments of the json func, at some point I get an [undefined], which causes the error.
I guess there's an error in config-chain.

parser signature is not respected

In utils.js, the signature of parse() is (content, file). From what I understand of the body of the parser, file should be the filename.

But from what I see in the module, I don't find a place where file is actually provided

Is it a mistake ?

Search in XDG environment variables

The XDG spec defines two environment variables ($XDG_CONFIG_HOME and $XDG_CONFIG_DIRS) in which to search for config files.

Since the majority of Linux desktops follow this standard, it's worth supporting these variables as well.

primitive key may get error

in folder lib utils.js

    if (cursor[_subkey] === undefined) {
        console.log('undefined ' + cursor);
        cursor[_subkey] = {}
    }

where cursor[_subkey] is a primitive value ,like boolean , cursor[_subkey] = {} may get undefined value.

so code below

    // Increment cursor used to track the object at the current depth
    cursor = cursor[_subkey]

will still got an undefind value.

I just don't much about rc, I found this problem when I install another project.

tks

fail with a descriptive error when a specified config file is not readable

I don't know if this is against the concept of rc, but when I specify a config file with --config I would like to see an error when I just typed the config path wrong for example.

the default behavior could produce hours of false debug sessions because I don't realize the config is just not loaded!

rc does not work well with webpack

I am working on packing up a project that references RC in electron & vue using webpack, and I've found that rc does not play nicely with webpack.

I'm getting the following error:

A JavaScript error occurred in the main process
Uncaught Exception:
Error: rc(name): name must be string

The offending lines in rc:

if(!module.parent) {
console.log(
JSON.stringify(module.exports(process.argv[2]), false, 2)
)
}

module.parent is not respected by webpack (nor will it be webpack/webpack#1569)

Yaml support

Is it planned? I am willing to make a pull request if it matches this module's vision.

Update ini dependency - strict mode issues

When using rc in strict mode I'm getting octal literal errors.

/Users/anthonator/Documents/Projects/sticksnleaves/pet-records/api/node_modules/pwny/node_modules/rc/node_modules/ini/ini.js:49
                  .replace(/\2LITERAL\\1LITERAL\2/g, '\1')

This looks to be caused by your dependency on the ini package.

According to this issue the problem has been acknowledged. Although the issue isn't closed this PR indicates that it's been fixed. Looking through master I see the change as well.

rc assumes that there is a home directory

This is not always true, unix daemons run without a HOME defined. Problem is reproduceable with rc unit tests:

% unset HOME; npm test

> [email protected] test /home/sam/w/contrib/rc
> set -e; node test/test.js; node test/ini.js


path.js:360
        throw new TypeError('Arguments to path.join must be strings');
              ^
TypeError: Arguments to path.join must be strings
    at path.js:360:15
    at Array.filter (native)
    at exports.join (path.js:358:36)
    at module.exports (/home/sam/w/contrib/rc/index.js:27:13)
    at Object.<anonymous> (/home/sam/w/contrib/rc/test/test.js:7:28)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
npm ERR! Test failed.  See above for more details.
npm ERR! not ok code 0

Feature request: JS support

That would be nice to support commonjs js.
Some library and modules might require a smart configuration that can involve regex for example (famous eg: webpack). That would be nice to have support for JS exported module too. Are you open to this enhancement?
I plan to use rc for cssnext and stylelint and it would be nice (especially for cssnext config that might require other modules/files).

Clarification on the defaults argument needed

From the documentation I would assume that the second argument for rc should always be an object.

Reviewing the code I noticed that there is also a handling for the default param being a string. I would assume that this was meant to be an option to pass a stringified JSON object as the defaults variable is handed to utils.json() then.

Looking through utils.json() the defaults var (which has to be a string at this point) is passed to utils.file(). This leads me to the conclusion that the second argument could also be a path to a .json or .ini file?

If that is right, I think it would be a good idea if this was documented.

badness ensues if the default configuration is frozen

trivial example:

var DEFAULTS = Object.freeze({baz: 'quux'});
// var DEFAULTS = {baz: 'quux'};
process.argv.push('--foo', 'bar');
console.log(require('rc')('test', DEFAULTS));

expected output:

{ baz: 'quux', _: [], foo: 'bar' }

actual output:

{ baz: 'quux' }

Add support for arays in env variables

In the current version, if an array is defined in an rc, there is no way to override it from env variables.
@azetilov has already made an implementation of this that attempts to parse the values.
Addressed in #98

rc file extensions are not ignored

Under the README section "Configuration File Formats", it says:

rc ignores file extensions of configuration files.

require('rc')('myapp') fails to find a file named .myapprc.json, and I don't see any part of the code that supports that behavior. Am I misunderstanding the description of this behavior in the README?

#! breaking webpack loaders

I'm using cross-env with webpack and running into this issue when encountering '#!' in rc...

ERROR in ./~/fsevents/~/rc/index.js
Module parse failed: /MyProfile/my-repo/node_modules/fsevents/node_modules/rc/index.js Un
expected character '#' (1:0)
You may need an appropriate loader to handle this file type.
| #! /usr/bin/env node
| var cc   = require('./lib/utils')
| var join = require('path').join

The reference to your repo is a nested dependency inside fsevents. I can do a PR if needed but I am uncertain how this particular module would work without that. Any thoughts or suggestions?

I am using Node v0.6.8 on Mac OSX and Webpack v2.3.2

Thanks in advance. Also -here is another Github Reference semi-related to this (Meteor)

Ability to specify an `appname`

Ability to specify an rc appname as a command-line option instead of providing it inline:

// somescript.js
var conf = require('rc')();
node somescript --rc foo
# will check for more config in .foorc, FOO-* env variables, etc.

Much like the --config option for specifying the location of other config files. It's easy to work around currently, but would be a nice convenience.

idea: detect sudo user

If the user is running the app as sudo,
detect the sudo user, and use that users HOME directory instead of root.

This would be a breaking change, but I feel this is a sensible thing to do.

Search for [appname]Config property in package.json file(s)

It's common these days to allow an [appname]Config property in package.json as an alternative to creating .[appname]rc file. I guess that the same search pattern (./ ../ ../../ ../../../) would apply: so in every directory you would look for both the rc file and the property. Here's a description of the behavior in ESLint: stylelint/stylelint#442 (comment)

I was just wondering if you are interested in adding this feature to rc. rc already knows where to look for config and how to merge configs, so I thought it might be fitting. What do you think?

Can't find config in local dir

I can't seem to get rc to behave like I assumed it would. I want to test loading my config by putting a .apprc file in my test directory. However, rc doesn't ever look there. I assumed it would look in the directory where the code was executing.

I have a project with the following directory structure:

/ +
  |
  -- lib +
        |
        -- loadConfig.js
  |
  -- test +
        |
        -- .apprc
        |
        -- testLoadConfig.js

loadConfig.js

var conf = require('rc')('app');

module.exports = function(options) {
  console.log(conf);

  return options;
};

testLoadConfig.js

var assert = require('assert');

var loadConfig = require('../lib/loadConfig');

describe('loadConfig', function() {
  it('should load rc config', function() {
    var config = loadConfig(); // assumed it would look for .apprc in project/test/.apprc

    console.log(config); // outputs { _: [] }
  });
});

I figure this is either designed this way intentionally or is a technical limitation but it's causing some heartburn so I thought I'd bring it up.

Pass the filepath to parse()

I would like to write a parser that resolves any values that are relative paths (starts with ./ or ../ and fs.existsSync returns true) to absolute paths. The parser would need to know the location of the file in order to be able to resolve a potential path and confirm the file exists.

I would submit a PR for this today, but I'm still trying to figunavigatere my company's open source contribution policy.

Support custom filepaths

Maybe accept a filepaths array instead of the first argument, e.g. rc(['./my/custom/path'])? Then also expose default paths as rc.paths(appname) (as function not array, for immutability), so that user can prepend/append/inject custom paths in their preferred order, e.g. rc(['./custom/path'].concat(rc.paths(appname)))?

I might be able to submit a PR if you'd be interested.

Making rc more configurable

We use rc for pnpm but we need the configs look exactly as they do with npm. Would you consider making rc more configurable to allow us rewrite some of the things?

Currently we need the possibility to use --userconfig instead of --config as the parameter for the config file. Related issue at pnpm pnpm/pnpm#40. Can this be made configurable?

Also rc currently uses the ${appname}_ prefix for env variables. It would be great to be able to specify this prefix as we need the npm_config_ prefix instead.

Allow to read file with same name after changing current working directory

Currently it seems rc caches the file content by name rather than using the full path of the file.
That create a situation in which a given filename won't be loaded if the same filename was loaded from another directory before.

Here is the steps to reproduce:

// File `/directory_1/myapprc`
property = 1
// File `/directory_2/myapprc`
property = 2
process.chdir('/directory_1');
var conf1 = require('rc')('myapprc');
console.log(conf1.property);
// 1

process.chdir('/directory_2');
var conf2 = require('rc')('myapprc');
console.log(conf2.property);
// 1 => should be 2

You should add a notice saying this is an npm module for node.js

I think you should add a notice saying this is an npm module for node.js

  • in the github repository header description
  • on top of the README file

... because I find it is not instantly clear, even if node developers like us finally see that relatively quickly.

Also, it could be more visible when a node developer search a solution for rc files (because of search engine look at these places)

How to define an Array in .ini format?

[myarray]
0 = value0
1 = value1
or
myarray = [ value0, value1, value3 ] ?

both do not work. One of my test results ...
myarr: { '0': '[one, two, three]', '1': '2nd' }

--config in the cli args

In the index.js file you are using:

cc.json(argv.config),

This causes a .config key to be added to the object returned by rc instead of merging its contents.
Since config is an object parsed by optimist, shouldn't it simple be like this?

argv.config,

Also you are doing argv in the end, merging every cli arguments into the rc object. Isn't this dangerous? This seems not the default behaviour wanted for most users. It could be an option if you really want it to be handled inside.

non-lowercase prefixes in env vars don't work

This change broke non-lowercase prefixes: b6c3d22

If prefix contains upper case characters, env vars won't load. For example the assertion below will fail but it should succeed:

process.env['CONF_key'] = 'value';
var conf = require('rc')('CONF');
assert.equal(conf.key, 'value'); // should succeed, but fails

Nested objects aren't merged

Nested objects aren't merged.

Say, you have a file like this:

rc('test',  {
  foo: {car: 'crash', bar: 'bla'}
})

and you run it with node test.js --foo.bar=blabla, then it'll spit out:

{
  foo: {bar: 'blabla'}
}

The car crash is gone.

Search for rc files down parent directories

It's common to have .{name}rc files for runtime configuration. One of the examples is twitter/bower, that supports .bowerrc (json). The name of the file is build upon the name passed into rc(name, defaults).

Questions:

  • Should rc support this? bower is doing this manually
  • How would the name be built, if the name contains dashes, underscores and other non-word chars?
  • Should the rc package look for the rc files upwards the directory tree, starting at process.cwd()?

LICENSE?

"BSD" is somewhat ambiguous. There are multiple open source licenses which can be considered "BSD".

Also, you should include the actual license in the repo (iirc all of the BSD licenses require it)

Improved support for environment variables

Hey,

The standard convention for environment variables is all upper case. In addition, environment variables don't support dashes. What I recommend is to take command line options and look for all upper case environment variables, replacing dashes with underscores, i.e.:

--phantmosjs-options -> MYAPP_PHANTOMJS_OPTIONS

Would you take a pull request for this?

problem parsing valid JSON array

My .rc file contains a valid JSON starting with a square bracket:

[
  { "hello": "world" }
]

And rc outputs the following:

{ '[': true,
  '{ "hello": "world" }': true,
  ']': true,
  _: [],
  configs: [ '/Users/tobiasreich/Sites/Rosid/.rosidrc' ],
  config: '/Users/tobiasreich/Sites/Rosid/.rosidrc' }

I tested the strip-json-comments module and it's not causing this problem. I guess it's because rc tries to merge the JSON with the defaults.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.