arcticicestudio / arctic Goto Github PK
View Code? Open in Web Editor NEWThe snowy home of Arctic Ice Studio
Home Page: https://www.arcticicestudio.com
License: Other
The snowy home of Arctic Ice Studio
Home Page: https://www.arcticicestudio.com
License: Other
Integrate Husky, the tool that make Git hooks easy and can prevent bad Git commits, pushes and more 🐶 woof!
The configuration file .huskyrc.js
will be placed in the project root and includes the command to run for any supported Git hook. It will at least contain configs for the following hooks:
pre-commit
- Run lint-staged
(#33) before each commit to ensure all staged files are compliant to all style guides..huskyrc.js
configuration file.Integrate ESLint, the pluggable and de-facto standard linting utility for JavaScript.
The configuration presets that will be used are @arcticicestudio/eslint-config that implements the Arctic Ice Studio JavaScript Style. It comes with the following peer dependencies:
It it built on top of @arcticicestudio/eslint-config-base that includes various rules of the following plugins and rule presets that are therefore also required peer dependencies:
Since arctic will be built with TypeScript, the @arcticicestudio/eslint-config-typescript preset will be extended to add support for TypeScript source file linting and compatibility with Prettier through the @arcticicestudio/eslint-config-typescript/prettier
extension entry point. This preset requires the following peer dependencies:
Since the custom presets are still in major version 0
note that the version range should be >=0.x.x <1.0.0
to avoid the “SemVer Major Zero Caveat”. When defining package versions with the the carat ^
or tilde ~
range selector it won't affect packages with a major version of 0
. yarn will resolve these packages to their exact version until the major version is greater or equal to 1
.
To avoid this caveat the more detailed version range >=0.x.x <1.0.0
should be used to resolve all versions greater or equal to 0.x.x
but less than 1.0.0
. This will always use the latest 0.x.x
version and removes the need to increment the version manually on each new release.
To allow to lint TypeScript code the @typescript-eslint/parser
parser will be used and specified as parser next to the main Babel parser. Also to make use of the latest experimental Babel features and proposals, eslint-plugin-babel will be added with the following rule configurations:
babel/camelcase
with level error
- doesn't complain about optional chaining (let foo = bar?.a_b;
). Note that the core rule camelcase
must be disabled!babel/no-unused-expressions
with level error
- doesn't fail when using do
expressions or optional chaining (a?.b()
). Note that the core rule no-unused-expressions
must be disabled!See the documentation of provided rulesand required configurations to use them.
The .eslintrc.js
configuration file will be placed in the project root next to the .eslintignore
file to define ignore pattern.
To prepare for a better developer experience with Webpack (that will be used later on through Gatsby) the resolvers of the eslint-plugin-import will be configured for the src
and src/components
paths.
To allow to run the JavaScript linting separately a lint:js
npm script/task will be added to be included in the main lint
script flow. To use the great auto-fixing feature another format:js
script/task will be added.
.eslintrc.js
configuration file.
babel/no-unused-expressions
and babel/camelcase
rules including the deactivation of their associated core rules.babel
to the array of enabled plugins..eslintignore
ignore pattern file.format:fix-js
, format:fix-ts
, lint:js
and lint:ts
scripts.Associated epic: #12
To achieve a consistent and uniform style and layout, the basic HTML elements, like e.g. a <h1>
or <ul>
should be used through a React component. These components render to the base HTML element they represent, but will apply styles, behavior and layout properties to ensure they match the project's design guidelines instead of using default browser configurations that might be even differ for each user agent.
This allows to use base HTML elements with all the advantages of React and JS without worrying about different render output.
This collection issue tracks the implementations of all the different individual React components. They are all based on the awesome MDN HTML elements reference documentation and will use the same categorization.
A
Implemented by:
-
Represents the <a>
HTML element (or anchor element). This is a special dynamic and failsafe component since it'll internally use Gatsby Link to route within the site (internal links) while also being able to link to external data.
This will be handled through a utility function to conditionally render based on the passed target URL (internal & external).
This epic documents the design concept for the React function and class components of arctic. The architecture and project structure is documented in the “Component & Project Structure” design concept.
🚧 This is a living document which means it is work in progress, not completed yet and will be extended!
GitHub provides a feature to define multiple issue templates.
The initial template file that has been used when the feature was introduced can now be used as a fallback/generic template.
The UI helps users to open a new issue in projects by prompting them to choose from multiple issue types.
See the GitHub Help for more details about issue and pull request templates. Also check out how to manually create issue templates and a pull request template. There's also a guide on how to create the (deprecated) fallback/generic issue template.
Add the LICENSE.md
file for the MIT license.
This epic documents the design concept of the static site generator that'll be used to build arctic’s and serves as a plan for the initial launch. It defines the process steps to decide about aspects like the Gatsby core configuration, Gatsby API implementations, required Gatsby plugins, custom configurations for Babel and Webpack and many more.
🚧 This is a living document which means it is work in progress, not completed yet and will be extended!
Gatsby is a blazing fast modern site generator to build secure, modern and blazing fast websites and apps with React. It is fully compliant to JAMstack which is the web development architecture used to built arctic as documented in #3.
Gatsby is much more than just a static “site” generator powered by React as explained by the founder and core team members:
It produces static HTML and then rehydrates into a React app.
Think of it as an opinionated CRA with built-in SSR and nice integrations with CMS.
Gatsby is also there to build apps. — Kyle Mathhews, Founder of Gatsby
Gatsby can handle apps with:
- User authentication? ✅
- Dynamic data? ✅
- Asynchronous requests? ✅
- Ecommerce? ✅
- Full-blown SaaS? ✅
You can do SO MUCH MORE than static sites with Gatsby. — Jason Lengstorf , Gatsby Core Team Developer
There are countless more features, but it is out of scope for this document to introduce these here. Instead, make sure to check their official project website with the extensive, well-written docs and really intense and beginner-friendly tutorials. It also includes a large overview and comparison of all features, a plugin library and inspiring showcases.
In their blog they publish a lot of great guides, tips & tricks and articles like how Gatsy got so popular that they founded Gatsby Inc. and blog posts about the companies feature plans and values.
To build arctic with Gatsby there are several process steps that must be planned and implemented. This section splits it up into categories and theirs tasks that will be documented and tracked within this epic.
On July 3rd 2019, the long-awaited Gatsby Themes API was announced.
This allows to extract logic and components into own packages that can be composed together for reuse in other Gatsby projects or as template/starter for new projects.
arctic will make use of this awesome feature by implementing splitting up into multiple scoped (@arcticicestudio
) packages for a simply modularized code base:
@arcticicestudio/gatsby-theme-arctic-core
— A Gatsby Theme that provides basic and essential plugins and configurations that can simply be used in other projects or serve as base theme. It'll try to be as generic as possible while still being dynamic configurable.@arcticicestudio/gatsby-theme-arctic-core
— The main Gatsby Theme that'll be more opinionated when it comes to CSS-in-JS libraries and usage of other larger projects/plugins that are not only targeted to basic/essential configurations. It will be the main source for core components and layouts that can be used to extend another Gatsby Theme on.www
— The package of the website itself. It will use and compose both Gatsby Theme packages and adds additional Gatsby plugins and configurations specific to the site as well as plugins that can only be applied in this package due to their required loading order (e.g. gatsby-plugin-offline
).Since arctic’s repository structure is a monorepo, the modular architecture comes with even more improvements like hoisted dependencies and a way smoother developer experience due to direct loading of local packages.
The core configuration of Gatsby is the gatsby-config.js
file that will be placed in the root directories of the theme and website packages. It defines project-wide site metadata that can be used through the GraphQL API and configures all plugins that will be used.
All implementation details and requirements are documented and tracked in the corresponding issues:
-
) „Gatsby initial configuration“ — in progress ∞Gatsby can be customized and extended to the core by providing…
gatsby-config.js
file placed in the project root.gatsby-ssr.js
file placed in the project root.gatsby-browser.js
file placed in the project root.All APIs come with a collection of functions called “Actions” that can be used to manipulate the build.
For more details make sure to read the API specification and philosophy and references for the GraphQL API.
All implementation details and requirements are documented and tracked in the corresponding issues:
-
) „Gatsby initial configuration“ — in progress ∞Gatsby is designed to be easily extensible while being functional out-of-the-box™. This is possible by using the powerful plugin API to simply create own plugins or browse the plugin library since there is already a large ecosystem and a plugin for almost everything.
arctic will make use of various plugins to implement features and simplify the code base for a better developer experience.
All implementation details and requirements are documented and tracked in the corresponding issues:
-
) „Gatsby initial configuration“ — in progress ∞Gatsby comes with an already optimized Babel configuration to create SSR “static” websites and apps, but there are also use cases that require to modify and extend this configuration to e.g. add a new Babel plugin for the latest syntax feature/proposal support.
Of course Gatsby provides a way through the Node API by implementing the onCreateBabelConfig
function.
All implementation details and requirements are documented and tracked in the corresponding issues:
-
) „Gatsby initial configuration“ — in progress ∞This is almost the same like the section above about how to modify and extend the Babel configuration but now for Webpack instead of Babel. This can be necessary to e.g. add a builtin or third-party plugin or to add resolve aliases. For sure Gatsby supports this too by providing the onCreateWebpackConfig
function through the Node API.
All implementation details and requirements are documented and tracked in the corresponding issues:
-
) „Gatsby initial configuration“ — in progress ∞Add the .yarnrc
and .npmrc
configuration files to enforce project-wide standards for all core team members and contributors. This includes the usage of the Yarn and npm exact
version resolution as well as disabling the creation of the npm package-lock.json
file in order to prevent conflicts with the yarn.lock
file.
This epic documents the design concept of arctic’s web development architecture and serves as a plan for the initial launch.
It defines the process steps of the three key criteria.
🚧 This is a living document which means it is work in progress, not completed yet and will be extended!
JAMstack: noun \’jam-stak’
Modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.
It is not about specific technologies, but a new way of building websites and apps that delivers better performance, higher security, lower cost of scaling, and a better developer experience.
A project is built with the JAMstack if it meets the three key criteria JavaScript, APIs and Markup:
Any dynamic programming during the request/response cycle is handled by JavaScript, running entirely on the client. This could be any frontend framework, library, or even vanilla JavaScript.
All server-side processes or database actions are abstracted into reusable APIs, accessed over HTTPS with JavaScript. These can be custom-built or leverage third-party services.
Templated markup should be prebuilt at deploy time, usually using a site generator for content sites, or a build tool for web apps.
For detailed information check out the official website that provides information about how projects can adapt to it, best practices, examples, resources and a great community.
Implementation issues: #4
Any dynamic programming during the request/response cycle is handled by JavaScript, running entirely on the client. This could be any frontend framework, library, or even vanilla JavaScript.
We 💙 React!
All web related projects developed by Arctic Ice Studio are built with React and we're not alone. React is not just a trend, it's more like a new standard how the web is built. It revolutionized the way to think about the components a website is made of and how to compose and orchestrate them to form a fluid running unit. It's finally a new way to solve the complicated topic of state handling and the most performant technique to update only necessary parts of the DOM without the large overhead to re-render it completely every time.
React describes itself as…
Next to this React can also render on the server using Node and power mobile apps using React Native.
There are so many more arguments and we think all most every developer heard or read about it so this little summary here is only a small introduction.
If you like to get to know more about React, your first touchpoint should be the official website and their extensive and absolute fantastic docs, tutorials and blog. They are maintained and well-written by the React core team itself and the contributors from one of the largest open source community. They are made with a flat learning curve in mind to be very beginner-friendly but at the same time are the main source for every advanced and experienced React developer. They increase the degree of knowledge up to deep-dives into the heart of React and include many great articles about best practices, how to increase the performance and maintainability of apps, the latest features and updates from the React ecosystem, tips & tricks of the core team and many more.
arctic will be built with the currently latest stable version 16.9.0, making use of the awesome Hooks, and will update and adapt to upcoming features like Suspend (aka Async Rendering) when they become stable to always enhance the project and code base.
All implementation details and requirements are documented and tracked in the corresponding issues:
-
) „Gatsby initial configuration“ — in progress ∞Implementation issues: #4
The plan is to make use of the official GitHub GraphQL API (v4) to get data about projects which can then be used to e.g. show the actual count of stars, the latest release version, interact with issues and pull requests and many more. There are also GitHub Apps that allow to work and interact with the projects.
More APIs might be added later on for many more flexible data fetching using the awesome GraphQL API provided by Gatsby (implemented in #4).
Implementation issues: #4
This criteria is the actual content of a website.
Gatsby (#4) allows to use Markdown for it. This comes with the nice side effect that the already existing documentations can simply be adapted and reused, but unfortunately it is limited to it's reduced and simplified syntax.
To use the great power of React this project will make use of the MDX specification, a new language and abstract syntax tree definition.
In order to ensure a vibrant ecosystem and community, tooling needs to exist for formatting, linting, and plugins. This tooling requires a foundational specification and abstract syntax tree so that parsing is properly handled before transforming to JSX/Hyperscript/React/etc and potentially leveraging existing plugin ecosystems.
We will use the official implementation, the fully-featured MDX parser, loader and JSX renderer to allow to seamlessly use JSX in Markdown documents by importing components and export metadata or any other ECMAScript compliant data structures like frontmatter.
- 💻 Everything is a component: Use existing components inside your MDX and import other MDX files as plain components.
- 🔧 Customizable: Decide which component is rendered for each Markdown element ({ h1: MyHeading }).
- 📚 Markdown-based: The simplicity and elegance of Markdown remains, you interleave JSX only when you want to.
- 🔥 Blazingly blazing fast: MDX has no runtime, all compilation occurs during the build stage.
More details are provided through the official website that includes docs to get started, usage examples and advanced configuration and customization information.
Add the EditorConfig file to define and maintain consistent coding styles between different editors and IDEs.
This epic documents the icon design concept of arctic Analytics and Statistics evaluation. It defines the process steps to decide about the usage reach and necessity as well as respecting the privacy of users.
🚧 This is a living document which means it is work in progress, not completed yet and will be extended!
Related epics: #6
The Root
core container will be the first and one of the important main data provider components of the main Gatsby Theme. It represents the base element and entry point that wraps custom application components and serves as a data provider later on. Some of the tasks in the future will be to
ThemeProvider
componentcreateglobalstyle
function including typography (#5) related data like application-wide used fontsRoot
that renders the passed children
within a React.Fragment
.Landing
root/index page rendering the Root
component.Initially implement the Gatsby theme and main website package configurations. The gatsby-config.js
files of each Gatsby Theme will define project-wide site metadata that can be used through the GraphQL API and configures all plugins that will be used including the Gatsby themes.
All metadata will be, like defined in #6, placed in the corresponding folders for configurations (src/config
) and data (src/data
). Initially this will include information stored in the package.json
file of the project. There will also be constants for important project root folders to be used in imports later on like route mappings.
This initial implementations will include the following basic plugins and packages, split up into the corresponding Gatsby theme packages.
@arcticicestudio/gatsby-theme-core
@arcticicestudio/gatsby-theme-arctic
www
To provide a simple development flow, new package scripts will be created to start the Gatsby’s development mode and build a production bundle. This also includes basic scripts like a clean up to remove possible cache problems and previously created bundles and the currently not available „collected“ scripts to run all scripts of the same type/task. The npm-run-all package will be used to simplify the scripts and prevent unnecessary long chained commands and OS related problems.
Gatsby comes with an already optimized Babel configuration to create SSR “static” websites and apps, but there are also use cases that require to modify and extend this configuration to e.g. add a new Babel plugin for the latest syntax feature/proposal support.
Of course Gatsby provides a way through the Node API by implementing the onCreateBabelConfig
function.
arctic will make use of the following proposals and plugins:
@babel/plugin-proposal-class-properties
(NOTE: This plugin will be configured with the enabled loose
option!)@babel/plugin-proposal-export-default-from
babel-plugin-react-remove-properties
to remove props from React elements like data-testid
attributes added for simplified querying in automated tests.The plugins and Babel options will be implemented using Gatsby’s provided actions setBabelPlugin
and setBabelOptions
.
This is almost the same like the modified Babel configuration documented above, but for the Webpack configuration instead. It will be used to
build
directory within the project root.~assets
➜ src/assets
~atoms
➜ src/atoms
~config
➜ src/config
~containers
➜ src/containers
~data
➜ src/data
~hooks
➜ src/hooks
~hooks
➜ src/layouts
~molecules
➜ src/molecules
~organisms
➜ src/organisms
~pages
➜ src/pages
~stores
➜ src/stores
~styles
➜ src/styles
~templates
➜ src/templates
~utils
➜ src/utils
Gatsby also supports this by providing the onCreateWebpackConfig
function through the Node API.
In order to make the Webpack alias imports with TypeScript, the module resolution will be configured to make the alias names and paths available to the compiler.
Since Gatsby v2, React is a peer dependency which allows users to freely choose the version they'd like to use. arctic will initially be build with the currently latest stable version 16.9.0.
setBabelPlugin
API function.https://github.com/oliviertassinari/babel-plugin-react-remove-properties
for production builds to remove data-testid
test attributes.git-revision-webpack-plugin
to provide the version, commit hash and branch as environment variables through through the webpack.DefinePlugin
.webpack-bundle-analyzer
to generate a “static” report with a JSON stats file stored in a newly created build
directory within the project root.Initialize the package.json
file that contains the project's metadata and Yarn workspace definitions.
This epic documents the design concept for the SEO (Search Engine Optimization) & social media representation of arctic.
🚧 This is a living document which means it is work in progress, not completed yet and will be extended!
This epic documents the design concept for the responsive web design pattern of arctic which is the most used, best thought out and Google’s recommended design pattern that provides a great user experience and the best SEO through multi-device & full mobile compatibility.
🚧 This is a living document which means it is work in progress, not completed yet and will be extended!
This epic documents the project concept and serves as a plan for the initial launch. It defines the web design process in several steps this project will go through. It is also the main issue to track all related sub-epics that contain detailed documentations about the concepts described in this issue.
🚧 This is a living document which means it is work in progress, not completed yet and will be extended!
The project should adapt to GitHub's code owners feature. This will allow to define matching pattern for project paths to automatically add all required reviewers of the core team and contributors to new PRs.
See GitHub Help for more details.
Integrate remark-lint which is built on remark, the powerful Markdown processor powered by plugins such as remark-lint.
Ensuring theMarkdown you (and contributors) write is of great quality will provide better rendering in all the different markdown parsers, and makes sure less refactoring is needed afterwards.
remark-lint can be used via remark-cli and a rule preset. This preset will be remark-preset-lint-arcticicestudio, the custom preset that implements the Arctic ice Studio Markdown Style Guide.
Since the custom preset is still in major version 0
note that the version range should be >=0.x.x <1.0.0
to avoid the “SemVer Major Zero Caveat”. When defining package versions with the the carat ^
or tilde ~
range selector it won't affect packages with a major version of 0
. yarn will resolve these packages to their exact version until the major version is greater or equal to 1
.
To avoid this caveat the more detailed version range >=0.x.x <1.0.0
should be used to resolve all versions greater or equal to 0.x.x
but less than 1.0.0
. This will always use the latest 0.x.x
version and removes the need to increment the version manually on each new release.
The .remarkrc.js
configuration file will be placed in the project root as well as the .remarkignore
file to also define ignore pattern.
To allow to run the Markdown linting separately a lint:md
package script/task will be added to be included in the main lint
script flow.
.remarkrc.js
configuration file..remarkignore
ignore pattern file.lint:md
script/task.Image source: Kent C. Dodds's awesome ["Testing JavaScript"][testingjavascript] workshop
All rights on the image belong to https://testingjavascript.com
This epic documents the design concept of the testing architecture of arctic to ensure the project has a high quality as much as possible. Therefore a setup of stable and proven testing principles, libraries and tools will be used which are tailored for React based projects.
🚧 This is a living document which means it is work in progress, not completed yet and will be extended!
Unfortunately it looks like the Netlify website host isn't hosting this site anymore.
This epic documents the design concept for the continuous deployment & hosting of arctic with Netlify, a fantastic and one of the most popular services providing a single, simplified deployment workflow and a great hosting performance through a ultra-redundant global Application Delivery Network. They invest a lot into the open source community by hosting public projects for free with a lot of features like HTTPS with a free TLS certificate via Let's Encrypt, custom domain, automated preview deployments through integrations with GitHub and many more awesome features.
Listing all of the almost endless features is out-of-scope of this document. The well-written and really extensive documentation contains all information to get started. It also includes a lot of videos in sections to introduce a feature or guide the user through a setup with a tutorial.
🚧 This is a living document which means it is work in progress, not completed yet and will be extended!
This issue documents arctic’s typography design concept and serves as a plan for the initial launch.
It defines the process steps to decide about all typography aspects like the font face, base sizes, usage within components/themes and the modular scale(s).
🚧 This is a living document which means it is work in progress, not completed yet and will be extended!
Associated epic(s): #4
Configure TypeScript, the typed superset of JavaScript that compiles to plain JavaScript.
This is the main language on which arctic will be built.
Like documented in the „Gatsby“ design concept, it will be used in combination with Gatsby later on with the gatsby-plugin-typescript
plugin.
Note that TypeScript is only used as linter/validator
and not as compiler. The actual compiler is Babel that is configured and used through Gatsby.
The root project will provide the main tsconfig
for all packages and the website itself.
To allow to run the TypeScript linting separately a lint:ts
package script will be added that'll also be run through the main lint
script flow.
tsconfig.json
file.lint:ts
script.Depends on #22
GitHub introduced a feature for recommended community standards. arctic tries to adhere to the great Open Source Guides and will adapt to the recommendations to complete the projects community profile.
To facilitate a healthy and constructive community behavior, arctic will adhere and enforce a code of conduct.
It will include sections about
See the GitHub Help for more details about the provided integrations.
The contribution guidelines help to build a community that encourages people to use, contribute to, and evangelize a project.
It will include sections about
See the GitHub introduction blog post and GitHub Help for more details about the provided integrations.
Add the .gitattributes
and .gitignore
configuration files to define the pattern.
Integrate lint-staged to run linters against staged Git files to prevent to add code that violates any style guide into the code base.
The configuration file lint-staged.config.js
will be placed in the project root and includes the command that should be run for matching file extensions (globs). It will include at least the three following entries with the same order as listed here:
prettier --list-different
- Run Prettier (#32) against *.{js,json,md,mdx,ts,tsx,yml}
to ensure all files are formatted correctly. The --list-different
prints the found files that are not conform to the Prettier configuration.eslint
- Run ESLint (#30) against *.{js,ts,tsx}
to ensure all TypeScript and JavaScript files are compliant to the style guide after being formatted with Prettier.remark --no-stdout
- Run remark-lint (#27) against *.md
to ensure all Markdown files are compliant to the style guide. The --no-stdout
flag suppresses the output of the parsed file content.lint-staged.config.js
configuration file.Add a Git mailmap file to link to in documentations to allow contributors to send mails regarding security issues. This prevents unnecessary overhead of updating all documents when new core team and members and contributors are added and additionally adds the main functionality of the file: Mapping commits when someone uses a different email address.
Integrate Prettier, the opinionated code formatter with support for many languages and integrations with most editors. It ensures that all outputted code conforms to a consistent style.
This is one of the main features of Prettier: It already provides the best and recommended style configurations of-out-the-box™.
The only option we will change is the print width. It is set to 80 by default which not up-to-date for modern screens (might only be relevant when working in terminals only like e.g. with Vim). It'll be changed to 120 used by all of Arctic Ice Studio's style guides.
The prettier.config.js
configuration file will be placed in the project root as well as the .prettierignore
file to also define ignore pattern.
To be fully compatible with ESLint, eslint-plugin-prettier has already been included in #30 as well as the set of recommended rules via the @arcticicestudio/eslint-config/prettier
and @arcticicestudio/eslint-config-typescript/prettier
extension entry points.
To allow to format all sources a format:pretty
package script will be added that'll also run in the main format
script flow.
A new lint:pretty
script will also allow to check if all supported files are correct formatted. It will be included in the main lint
script flow.
prettier.config.js
configuration file..prettierignore
ignore pattern file.format:pretty
package script and add to main format
script flow.A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.