├── .github ├── CONTRIBUTING.md ├── ISSUE_TEMPLATE.md ├── PULL_REQUEST_TEMPLATE.md ├── commit-message-convention.md ├── contribute-by-reporting-issue.md ├── development-environment.md ├── pull-request-guideline.md ├── release-note-guideline.md └── repository-setting.md ├── LICENSE └── README.md /.github/CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # How to Contribute 2 | 3 | > This Guide is base on [CocoaPods](http://guides.cocoapods.org/contributing/contribute-to-cocoapods.html), [ESLint](http://eslint.org/docs/developer-guide/contributing/) 4 | 5 | ## [Filing Issues](contribute-by-reporting-issue.md) 6 | Bug Reporting 7 | Propose a New Feature 8 | Requesting a change 9 | 10 | ## [Submitting a Pull Request](pull-request-guideline.md) 11 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | 11 | 12 | 13 | ## Version 14 | 15 | 16 | 17 | ## Development Environment 18 | * Browser: 19 | * OS: 20 | 21 | ## Install by 22 | - [ ] bower 23 | - [ ] npm 24 | - [ ] I only have `dist/tui-xxx-xxx.js` 25 | 26 | ## Current Behavior 27 | 28 | 29 | ```javascript 30 | // sample code 31 | ``` 32 | 33 | ## Expected Behavior 34 | 35 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | > reference [Vuejs](https://github.com/vuejs/vue/blob/dev/.github/PULL_REQUEST_TEMPLATE.md), [OpenSource.guide](https://opensource.guide/best-practices/) 2 | 3 | 9 | 10 | 11 | Fix: 12 | Resolve: 13 | 14 | ### What kind of change does this PR introduce? (check at least one) 15 | - [ ] Bugfix 16 | - [ ] Feature 17 | - [ ] Update 18 | - [ ] Code Style Update 19 | - [ ] Refactor 20 | - [ ] Build-related changes 21 | - [ ] Other, please describe: improvement 22 | 23 | ### Does this PR introduce a breaking change? (check one) 24 | - [ ] Yes 25 | - [ ] No 26 | 27 | ### Please check if the PR fulfills these requirements 28 | - [ ] It's submitted to `develop` branch, __not__ the `master` branch 29 | - [ ] When resolving a specific issue, it's referenced in the PR's title (e.g. `fix #xxx[,#xxx]`, where "xxx" is the issue number) 30 | - [ ] The commit message follows our guidelines 31 | - [ ] Tests for the changes have been added (for bug fixes / features) 32 | - [ ] Docs have been added / updated (for bug fixes / features) 33 | 34 | ### Other information 35 | 36 | --- 37 | Thank you for your contributing to TUI product. 🎉 😘 ✨ 38 | You can expect a response from a maintainer within 7 days. 39 | If you haven’t heard anything by then, feel free to ping the thread. 40 | -------------------------------------------------------------------------------- /.github/commit-message-convention.md: -------------------------------------------------------------------------------- 1 | # TOAST UI Commit Message Convention 2 | 3 | > reference [AngularJS](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#-git-commit-guidelineses), [ESLint](https://eslint.org/docs/developer-guide/contributing/pull-requests#step-2-make-your-changes) 4 | 5 | ## Commit Message Format 6 | 7 | ``` 8 | : Short description (fix #1234) 9 | 10 | Logger description here if necessary 11 | 12 | BREAKING CHANGE: only contain breaking change 13 | ``` 14 | * Any line of the commit message cannot be longer 100 characters! 15 | 16 | ### Revert 17 | ``` 18 | revert: commit 19 | 20 | This reverts commit 21 | More description if needed 22 | ``` 23 | 24 | ### Type 25 | Must be one of the following: 26 | 27 | * **feat**: A new feature 28 | * **fix**: A bug fix 29 | * **docs**: Documentation only changes 30 | * **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) 31 | * **refactor**: A code change that neither fixes a bug nor adds a feature 32 | * **perf**: A code change that improves performance 33 | * **test**: Adding missing or correcting existing tests 34 | * **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation 35 | 36 | ### Subject 37 | * use the imperative, __present__ tense: "change" not "changed" nor "changes" 38 | * don't capitalize first letter 39 | * no dot (.) at the end 40 | * reference GitHub issues at the end. If the commit doesn’t completely fix the issue, then use `(refs #1234)` instead of `(fixes #1234)`. 41 | 42 | ### Body 43 | 44 | * use the imperative, __present__ tense: "change" not "changed" nor "changes". 45 | * the motivation for the change and contrast this with previous behavior. 46 | 47 | ### BREAKING CHANGE 48 | * This commit contains breaking change(s). 49 | * start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this. 50 | -------------------------------------------------------------------------------- /.github/contribute-by-reporting-issue.md: -------------------------------------------------------------------------------- 1 | # Register Issue 2 | 3 | > references [ESLint](http://eslint.org/docs/developer-guide/contributing/) 4 | 5 | ## Bug Report 6 | Create a new issue if you found a new issue, or have a question. 7 | Please fill out [issue template]() to help us understand your report. 8 | 9 | ## Issue Classification 10 | > references [Robin Powered](https://robinpowered.com/blog/best-practice-system-for-organizing-and-tagging-github-issues/), 11 | [roslyn/wiki](https://github.com/dotnet/roslyn/wiki/Labels-used-for-issues), [dany lunny](https://medium.com/@dave_lunny/sane-github-labels-c5d2e6004b63), 12 | [ESLint](http://eslint.org/docs/developer-guide/contributing/working-on-issues) 13 | 14 | ### Examination 15 | * **triage** - not yet checked 16 | * **accepted** - issue was checked, and we agree on your report. 17 | * **invalid** - don't fit issue format 18 | * **wontfix** - determined by policy, may be it could resolved by other approach, or it's need much resource than it's usages 19 | * **duplicate** - have similar issue report 20 | 21 | ### Type 22 | * **bug** - need fix 23 | * **documentation** - need update document not a code. (e.g. comment, README) 24 | * **feature** - request new feature 25 | * **enhancement** - request updating exist feature 26 | * **question** - can help you by correct miss understanding point 27 | 28 | ### Status 29 | * **in progress** - started working 30 | * **in review** - resolved issue, and ready to submit PR for review 31 | 32 | ## Communicate with label 33 | As explained above, there are three type of label. Same type cannot assigned at the same type. 34 | It represent progress of issue. If there is no labeling or no comment in 7 days, ping us! 35 | 36 | ### Wait Examination 37 | When new issue is registered, the default label is __triage__. 38 | It has only one label(triage) until we review it. 39 | 40 | ### Sort issue 41 | - acceptable 42 | label changed to __acceptable__. 43 | A __well-chosen TYPE label__ will be assigned. 44 | When resolving starts, __STATUS label__ will be added. 45 | 46 | - not acceptable 47 | label changed to one of __inactive label__(invalid, wontfix, duplicate). 48 | 49 | ### Close issue 50 | Close issue, if it is __resolved__ or __inactive__. 51 | -------------------------------------------------------------------------------- /.github/development-environment.md: -------------------------------------------------------------------------------- 1 | # Development environment 2 | 3 | > references [ESLint](http://eslint.org/docs/developer-guide/development-environment) 4 | 5 | This is a step-by-step guide to setting up a local development environment that will let you contribute back to the project. 6 | 7 | ## Install Node.js 8 | Go to http://nodejs.org/ to download and install the latest stable version for your operating system. 9 | 10 | Most of the installers come with npm already installed, but if for some reason it doesn’t work on your system, you can install it manually using the instructions on the website. 11 | 12 | ## Fork and checkout your own ESLint repository 13 | Go to [TUI Github Repository][#TUI-Github-Repository] and click the “Fork” button. Follow the GitHub documentation for forking and cloning. 14 | 15 | Once you’ve cloned the repository, run npm install to get all the necessary dependencies: 16 | 17 | ```sh 18 | $ cd [tui-root-directory] 19 | $ npm install 20 | ``` 21 | 22 | You must be connected to the Internet for this step to work. You’ll see a lot of utilities being downloaded. 23 | 24 | ## Add the upstream source 25 | The upstream source is the main TUI repository that active development happens on. While you won’t have push access to upstream, you will have pull access, allowing you to pull in the latest code whenever you want. 26 | 27 | To add the upstream source for TUI item, run the following in your repository: 28 | 29 | ```sh 30 | $ git remote add origin [clone-link] 31 | ``` 32 | 33 | Now, the remote upstream points to the upstream source. 34 | 35 | 36 | ## Run the tests 37 | Running the tests is the best way to ensure you have correctly set up your development environment. Make sure you’re in the eslint directory and run: 38 | 39 | ```sh 40 | $ npm run test 41 | ``` 42 | The testing takes a few seconds to complete. If any tests fail, that likely means one or more parts of the environment setup didn’t complete correctly. The upstream tests always pass. 43 | 44 | ```sh 45 | $ npm run lint 46 | ``` 47 | Runs just the JavaScript linting on the repository 48 | 49 | ## Workflow 50 | Whenever you make changes to source files, you’ll need to run npm test to rerun the tests. The workflow is: 51 | 52 | 1. Make changes 53 | 2. Run npm test to run tests on the command line 54 | 55 | You’ll have to do this each time you make a change. The tests are run automatically whenever a pull request is received, so make sure to verify your changes work before submitting them. 56 | -------------------------------------------------------------------------------- /.github/pull-request-guideline.md: -------------------------------------------------------------------------------- 1 | # Pull Requests 2 | 3 | > This Guide is base on [CocoaPods](http://guides.cocoapods.org/contributing/contribute-to-cocoapods.html), [ESLint](http://eslint.org/docs/developer-guide/contributing/pull-requests) 4 | 5 | Development Workflow 6 | - Set up your development environment with [develoment environment](development-environment.md) 7 | - Pick up an [Issue](https://github.nhnent.com/youjung-hong/tui-github-guide/issues). See issue classification explained below 8 | - Check the CONTRIBUTING requirements 9 | - Make a pull request 10 | 11 | ## Pick up an issue 12 | [Issue Classification](contribute-by-reporting-issue.md#issue-classification) will help you to pick up an issue. 13 | Create master issue, if issues are too small 14 | 15 | ## Make changes 16 | ### Checkout New branch 17 | **Default Branches** 18 | - master: lastest release branch 19 | - develop: PR base branch, developing now 20 | - gh-pages: api docs and examples 21 | 22 | **Branch Naming Guide** 23 | 24 | > reference [ikaruce/git-style-guide#branches](https://github.com/agis/git-style-guide#branches) 25 | 26 | ``` 27 | (/short-description)/ 28 | ``` 29 | * ``: [commit message type](https://github.nhnent.com/youjung-hong/tui-github-guide/blob/master/.github/commit-message-convention.md#type), issue, issues 30 | * Choose __short__ and __descriptive__ names 31 | * Use __hyphens__ to separate words 32 | * Identify GitHub __issue__ or __pull request__ number   33 | 34 | **Good** 35 | ``` 36 |    fix/indentation-error/122 37 |    issues/update-documentaion/145-134-133 // 이슈 여러 개 38 |    issues/focus-blur/124 // 마스터 이슈 39 |    refactor/correct-typos/123 40 | feat/multiline-ternary-option/44 41 | issue/npm-publish/13 42 | ``` 43 | 44 | ### Check Code Style 45 | Run `npm run eslint` and make sure all the tests pass. Fail even WARNING! 46 | 47 | ### Test 48 | Run `npm run test` and verify all the tests pass. 49 | If you are adding new commands or features, they must include tests. 50 | If you are changing functionality, update the tests if you need to. 51 | 52 | ### Commit 53 | Follow our [commit message-conventions](commit-message-convention.md).   54 | Run `npm run check-commit` and check commit message format. 55 | 56 | ## Yes! Pull request 57 | Make your pull request, then describe your changes. 58 | ### Title 59 | Follow other PR title format on below. 60 | ``` 61 | : Short Description (close: #xxx) 62 | : Short Description (fix: #111) 63 | : Short Description (fix: #123, #111, #122) 64 | : Short Description (ref: #111) 65 | ``` 66 | * capitalize first letter of Type 67 | * use present tense: 'change' not 'changed' or 'changes' 68 | 69 | ### Description 70 | If it is related to an issue, add a link to the issue(like `#12`) in the description. 71 | Fill in the [PULL_REQUEST_TEMPLATE](PULL_REQUEST_TEMPLATE.md) by check your case. 72 | 73 | ## After merged 74 | Congulatulation! After merged, your branch is unnecessary. Please **delete your PR branch**. 75 | -------------------------------------------------------------------------------- /.github/release-note-guideline.md: -------------------------------------------------------------------------------- 1 | # Release Note Guide 2 | 3 | > references [ESLint](http://eslint.org/blog/), [Vuejs](https://github.com/vuejs/vue/releases) 4 | 5 | ## Title 6 | * should be a tag name. 7 | * follows [semantic versioning](http://semver.org/). 8 | 9 | * If this published to **npm**, tag name should start with `v` to avoid conflict with semver. For more information see [this](https://docs.npmjs.com/getting-started/using-tags#caveats). 10 | 11 | - - - 12 | 13 | ## Description Format 14 | ``` 15 | ## Highlights 16 | * Short Description on change 17 | more descriptions if necessary 18 | * Short Description on change 19 | * Short Description on change 20 | - - - 21 | 22 | 23 | ``` 24 | 25 | ### Highlights Description 26 | * summary of this release, user should know. 27 | * can be anything in ``. It could be a bug fix, updating feature, add new feature, etc. 28 | * order __Short Description__ by importance 29 | 30 | ### Changes 31 | ``` 32 | ## 33 | * () 34 | 35 | ## 36 | * () 37 | * () (@) 38 | ``` 39 | * `` is a last merge commit, before PR received. 40 | * add `` only if contributer is not manitainer/owner. 41 | 42 | ### Type of Changes 43 | * **Features** - Commit start with `New`, `feat` 44 | * **Enhancements** - Commit start with `Update`, `refactor`, `perf` 45 | * **Bug Fixes** - Commit start with `fix` 46 | * **Documentation** - Commit start with `docs` 47 | * **Chores** - Commit start with `style`, `test`, `chore` 48 | -------------------------------------------------------------------------------- /.github/repository-setting.md: -------------------------------------------------------------------------------- 1 | # Repository Settings 2 | 3 | ## Restrict editing to collaborators only 4 | Setting Tab > Options(default) > Features 5 | 6 | - [x] Wikis 7 | - [ ] Restrict editing to collaborators only 8 | - [x] Issues 9 | - [x] Project 10 | 11 | ## Enable squash merge only 12 | Setting Tab > Options(default) > Merge button 13 | 14 | - [ ] Allow merge commits 15 | - [x] Allow squash merging 16 | - [ ] Allow rebase merging 17 | 18 | ## Protect Default Branches from Merge 19 | Setting Tab > Branches > Protected branches > Choose a branch.. Dropdown 20 | 21 | ### Master, Support branch 22 | - [x] Protect this branch 23 | - [x] Require pull request reviews before merging 24 | - [ ] Dismiss stale pull request approvals when new commits are pushed 25 | - [x] Require status checks to pass before merging 26 | - [ ] Require branches to be up to date before merging 27 | - [x] Include administrators 28 | 29 | ### Develop, develop 30 | - [x] Protect this branch 31 | - [x] Require pull request reviews before merging 32 | - [ ] Dismiss stale pull request approvals when new commits are pushed 33 | - [x] Require status checks to pass before merging 34 | - [ ] Require branches to be up to date before merging 35 | - [ ] Include administrators 36 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | The MIT License 2 | 3 | Copyright (c) 2018 NHN Entertainment Corp. 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in 13 | all copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 21 | THE SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # ⚠️Notice: 이 레포지토리는 deprecated 상태이며 더 이상 업데이트 되지 않습니다. 2 | 3 | 이 레포지토리는 더 이상 관리되지 않으며, TOAST UI 어플리케이션과 컴포넌트에 대한 정보는 [TOAST UI Brand Site](https://ui.toast.com) 에서 보실 수 있습니다. Brand Site 에서 제품군 외에도 매주 업데이트되는 [Weekly-pick](https://ui.toast.com/weekly-pick/ko/)과 FE개발랩의 노하우를 담은 [FE 개발 가이드](https://ui.toast.com/fe-guide/ko/)도 보실 수 있으니 참조해주세요! 4 | 5 | FE개발 6 | ====================== 7 | FE개발랩에서 프로젝트 및 내부 과제를 수행하면서 생산한 기술 산출물로, 공통 모듈 및 컴포넌트와 개발 가이드 등을 포함합니다.
8 | 배포되는 산출물은 FE개발랩에서 개발/관리하며 [MIT 라이선스](LICENSE)로 자유롭게 사용할 수 있습니다.
9 | 단, FE개발랩의 동의 없이 임의로 수정하여 사용된 코드에 대해서는 유지보수 및 산출물의 품질을 보증을 할 수 없으니,
10 | 추가/수정 요청 및 문의, 버그 신고는 [[FE개발랩 DL]](mailto:dl_javascript@nhn.com)을 이용해주세요.
11 | 12 | 13 | ![brandsite](https://user-images.githubusercontent.com/37766175/73819167-50d62e80-4832-11ea-8fb4-5e15ec92d665.png) 14 | --------------------------------------------------------------------------------