{"id":20448532,"url":"https://github.com/datacamp/jsconfig","last_synced_at":"2025-04-13T01:26:50.720Z","repository":{"id":38425789,"uuid":"201414751","full_name":"datacamp/jsconfig","owner":"datacamp","description":"All the dotfiles for javascript @ DataCamp","archived":false,"fork":false,"pushed_at":"2025-02-10T13:17:49.000Z","size":1727,"stargazers_count":20,"open_issues_count":5,"forks_count":3,"subscribers_count":14,"default_branch":"main","last_synced_at":"2025-03-26T08:16:50.074Z","etag":null,"topics":["javascript","js","jsconfig"],"latest_commit_sha":null,"homepage":null,"language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/datacamp.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-08-09T07:25:12.000Z","updated_at":"2025-02-10T13:17:51.000Z","dependencies_parsed_at":"2025-01-16T06:33:33.042Z","dependency_job_id":null,"html_url":"https://github.com/datacamp/jsconfig","commit_stats":{"total_commits":279,"total_committers":16,"mean_commits":17.4375,"dds":"0.46953405017921146","last_synced_commit":"04dd2aafa2f052784e3bf9c15b0ff0a365be7921"},"previous_names":["datacamp-engineering/jsconfig"],"tags_count":26,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/datacamp%2Fjsconfig","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/datacamp%2Fjsconfig/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/datacamp%2Fjsconfig/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/datacamp%2Fjsconfig/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/datacamp","download_url":"https://codeload.github.com/datacamp/jsconfig/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248534510,"owners_count":21120352,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["javascript","js","jsconfig"],"created_at":"2024-11-15T10:35:35.651Z","updated_at":"2025-04-13T01:26:50.700Z","avatar_url":"https://github.com/datacamp.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# JSConfig\n\nThis repo provides a set of npm packages that configure the awesome tooling we use every day. There are a lot of these standards out there, but as a company we have specific needs, so this is here to serve us in the best way.\n\nAlso, when you have too many standards, xkcd recommends to create a new standard ([Source](https://xkcd.com/927/)).\n\n## Vision\n\nBy having a vision, we can make some decisions more easily by refering back to this vision and how a change contributes to this vision.\n\nThe goal of JS Config is to improve the productivity of our developers (in the long term). This means we should strive for (in order of importance):\n\n1. _Consistency_: auto-formatting / auto-sorting stuff: Developers should not need to think about this stuff and still find their code in a readable and consistent order / syntax. There shouldn't be a lot of discussion about which style to pick as it's just a matter of taste and getting used too. Let's try to stay as close as possible to \"community standards\".\n1. _Correctness_: small bugs (e.g. eslint rules about hooks) should be catched by eslint not by (human) reviews. Rules that catch potential bugs and with few false positives should be enabled.\n1. _Code Quality_: Rules that help in code quality and are not flagging too many false positives could be enabled as well.\n1. _Unity_: Having as many configs as possible in this repo and use it in as many projects as possible with at little adaptation as possible (but adaptation is still allowed!). That way engineers can assume a good and working setup and don’t need to catch little bugs during review time if a linter can do this.\n\n## Installation :floppy_disk:\n\n(If you are using npm, you should use `npm install` instead of `yarn add`)\n\n### ESlint :wrench:\n\n```bash\nyarn add -D eslint @datacamp/eslint-config\n```\n\nCreate a file `.eslintrc.js` with the following contents\n\n```js\n// .eslintrc.js\nmodule.exports = {\n  extends: ['@datacamp/eslint-config'],\n};\n```\n\nFor typescript projects you can use the following config:\n\n```js\n// .eslintrc.js\nmodule.exports = {\n  extends: ['@datacamp/eslint-config/typescript'],\n};\n```\n\nOr even better if you also want to enable a bunch of rules for which type-information is needed\n\n```js\n// .eslintrc.js\nconst path = require('path');\n\nmodule.exports = {\n  extends: ['@datacamp/eslint-config/typescript-with-type-information'],\n  parserOptions: {\n    project: path.join(__dirname, './tsconfig.eslint.json'),\n    tsconfigRootDir: __dirname,\n  }\n};\n\n// tsconfig.eslint.json\n{\n  \"exclude\": [\"node_modules\", \"**/node_modules\", \"**/dist\"],\n  \"extends\": \"./tsconfig.json\", // Make sure to let this point to your local tsconfig.json\n  \"include\": [\"**/*\", \".eslintrc.js\"]\n}\n```\n\nFeel free to configure the `parserOptions` differently. But this setup should hopefully work for most repositories. There is more documentation available ([[1](https://typescript-eslint.io/linting/typed-linting/)], [[2](https://typescript-eslint.io/linting/typed-linting/monorepos)] \u0026 [[3](https://typescript-eslint.io/architecture/parser/#project)])\n\nFor front-end projects, you might want to adjust the environment:\n\n```js\n// .eslintrc.js\nmodule.exports = {\n  // [...]\n  env: {\n    browser: true,\n  },\n};\n```\n\nAfterwards you can run eslint as follows:\n\n```bash\nyarn eslint . --ext ts,tsx,js,json --ignore-path .gitignore\n```\n\nIt's recommended to:\n\n- also install our common prettier config (as ESlint config uses your prettier config to lint for code style)\n- install an eslint plugin for your editor of choice (to see errors / warnings in your editor)\n\n### Prettier :nail_care:\n\n```bash\nyarn add -D prettier @datacamp/prettier-config\n```\n\nCreate a file `prettier.config.js` with the following contents\n\n```js\n// prettier.config.js\nmodule.exports = {\n  ...require('@datacamp/prettier-config'),\n};\n```\n\nIt's recommended to:\n\n- also install eslint to check whether your files are following your prettier config.\n- install prettier plugin for your editor of choice\n\n### NestJS :lion:\n\nFor DI to properly consume Reflect metadata add to your `.eslintrc.js` file:\n```\nparserOptions: {\n  emitDecoratorMetadata: true,\n}\n```\n\nIt causes TypeScript to create references to value imports when they are used in a type-only location.\n\nMore context [here](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/consistent-type-imports.md#usage-with-emitdecoratormetadata)\n\n## Contribute :family:\n\n### Developer guide\n\nAll the configs are in the `packages/` directory. We use [lerna](https://github.com/lerna/lerna) to manage dependencies.\n\nInstall the dependencies for all the subpackages using `yarn` in the root of the project.\n\nIf you need help, ping the #javascript channel on Slack.\n\n### Decisions process :hocho:\n\n1. Try out the configuration in your own project for a while (so the cost / benefit trade-off becomes more apparent)\n1. Create a PR (or an issue with a proposal if the PR would be a lot of work) outlying the changes + why it's a good idea. You can refer to the vision on what level it improves developer productivity (Consistency, Correctness, Code Quality, Unity).\n1. Communicate proposal in #javascript channel on Slack\n1. On the next javascript guild meeting, we go over all open PRs and quickly discuss as a group on whether we think it's a good idea. For this, we base ourselves on the vision. A change that fits the vision well has a higher chance of getting merged.\n\n### Commit messages\n\nWe use [commitlint]() to lint our commit messages and follow [config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional#type-enum). The version of the packages will be bumped based on the commit messages as well, see [the conventional commits website](https://www.conventionalcommits.org/en/v1.0.0/) for more information (short version: fix=patch, feat=minor, BREAKING CHANGE footer=major)\n\nIt's hard to know what is a breaking change so these our the guidelines:\n\n- It's a breaking change if it adds new errors that are not auto-fixable. So after running eslint --fix you should be good again and you just need to review the things it fixed\n- It's a breaking change if it expects to change a lot of code on --fix E.g. object literal properties should be ordered (it's auto fixable but it's gonna mess up a lot of code). Most prettier changes will also fall under this\n\nSo in short, users should be able to run `eslint --fix` (or equivalent) and review a few things but it should be doable to review in \u003c10 minutes, even for large projects.\nOther changes could qualify as well but then we basically always have major changes and almost never minor so that's why we choose these guidelines (for now). We're open to change them if they don't work for us.\n\n### Publishing\n\nYou can publish all the packages you've edited. This will run `lerna publish` under the hood:\n\n```bash\nyarn release\n```\n\nThis will propose version numbers for you and push a commit with a changelog to all the individual packages.\n\n_Please only run this from main and make sure to pull the latest main before you run it._ Running it will push a commit to main which the updated changelog etc.\n\n## Example Projects using JSConfig\n\n- [DataCamp's Design System](https://github.com/datacamp/design-system)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdatacamp%2Fjsconfig","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdatacamp%2Fjsconfig","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdatacamp%2Fjsconfig/lists"}