16 |
--------------------------------------------------------------------------------
/_posts/2015-05-11-welcome-to-jekyll.markdown:
--------------------------------------------------------------------------------
1 | ---
2 | layout: post
3 | title: "Welcome to Jekyll!"
4 | date: 2015-05-11 13:47:51
5 | categories: jekyll update
6 | ---
7 | You’ll find this post in your `_posts` directory. Go ahead and edit it and re-build the site to see your changes. You can rebuild the site in many different ways, but the most common way is to run `jekyll serve`, which launches a web server and auto-regenerates your site when a file is updated.
8 |
9 | To add new posts, simply add a file in the `_posts` directory that follows the convention `YYYY-MM-DD-name-of-post.ext` and includes the necessary front matter. Take a look at the source for this post to get an idea about how it works.
10 |
11 | Jekyll also offers powerful support for code snippets:
12 |
13 | {% highlight ruby %}
14 | def print_hi(name)
15 | puts "Hi, #{name}"
16 | end
17 | print_hi('Tom')
18 | #=> prints 'Hi, Tom' to STDOUT.
19 | {% endhighlight %}
20 |
21 | Check out the [Jekyll docs][jekyll] for more info on how to get the most out of Jekyll. File all bugs/feature requests at [Jekyll’s GitHub repo][jekyll-gh]. If you have questions, you can ask them on [Jekyll’s dedicated Help repository][jekyll-help].
22 |
23 | [jekyll]: http://jekyllrb.com
24 | [jekyll-gh]: https://github.com/jekyll/jekyll
25 | [jekyll-help]: https://github.com/jekyll/jekyll-help
26 |
--------------------------------------------------------------------------------
/_sass/_base.scss:
--------------------------------------------------------------------------------
1 | /**
2 | * Reset some basic elements
3 | */
4 | body, h1, h2, h3, h4, h5, h6,
5 | p, blockquote, pre, hr,
6 | dl, dd, ol, ul, figure {
7 | margin: 0;
8 | padding: 0;
9 | }
10 |
11 |
12 |
13 | /**
14 | * Basic styling
15 | */
16 | body {
17 | font-family: $base-font-family;
18 | font-size: $base-font-size;
19 | line-height: $base-line-height;
20 | font-weight: 300;
21 | color: $text-color;
22 | background-color: $background-color;
23 | -webkit-text-size-adjust: 100%;
24 | }
25 |
26 |
27 |
28 | /**
29 | * Set `margin-bottom` to maintain vertical rhythm
30 | */
31 | h1, h2, h3, h4, h5, h6,
32 | p, blockquote, pre,
33 | ul, ol, dl, figure,
34 | %vertical-rhythm {
35 | margin-bottom: $spacing-unit / 2;
36 | }
37 |
38 |
39 |
40 | /**
41 | * Images
42 | */
43 | img {
44 | max-width: 100%;
45 | vertical-align: middle;
46 | }
47 |
48 |
49 |
50 | /**
51 | * Figures
52 | */
53 | figure > img {
54 | display: block;
55 | }
56 |
57 | figcaption {
58 | font-size: $small-font-size;
59 | }
60 |
61 |
62 |
63 | /**
64 | * Lists
65 | */
66 | ul, ol {
67 | margin-left: $spacing-unit;
68 | }
69 |
70 | li {
71 | > ul,
72 | > ol {
73 | margin-bottom: 0;
74 | }
75 | }
76 |
77 |
78 |
79 | /**
80 | * Headings
81 | */
82 | h1, h2, h3, h4, h5, h6 {
83 | font-weight: 300;
84 | }
85 |
86 |
87 |
88 | /**
89 | * Links
90 | */
91 | a {
92 | color: $brand-color;
93 | text-decoration: none;
94 |
95 | &:visited {
96 | color: darken($brand-color, 15%);
97 | }
98 |
99 | &:hover {
100 | color: $text-color;
101 | text-decoration: underline;
102 | }
103 | }
104 |
105 |
106 |
107 | /**
108 | * Blockquotes
109 | */
110 | blockquote {
111 | color: $grey-color;
112 | border-left: 4px solid $grey-color-light;
113 | padding-left: $spacing-unit / 2;
114 | font-size: 18px;
115 | letter-spacing: -1px;
116 | font-style: italic;
117 |
118 | > :last-child {
119 | margin-bottom: 0;
120 | }
121 | }
122 |
123 |
124 |
125 | /**
126 | * Code formatting
127 | */
128 | pre,
129 | code {
130 | font-size: 15px;
131 | border: 1px solid $grey-color-light;
132 | border-radius: 3px;
133 | background-color: #eef;
134 | }
135 |
136 | code {
137 | padding: 1px 5px;
138 | }
139 |
140 | pre {
141 | padding: 8px 12px;
142 | overflow-x: scroll;
143 |
144 | > code {
145 | border: 0;
146 | padding-right: 0;
147 | padding-left: 0;
148 | }
149 | }
150 |
151 |
152 |
153 | /**
154 | * Wrapper
155 | */
156 | .wrapper {
157 | max-width: -webkit-calc(#{$content-width} - (#{$spacing-unit} * 2));
158 | max-width: calc(#{$content-width} - (#{$spacing-unit} * 2));
159 | margin-right: auto;
160 | margin-left: auto;
161 | padding-right: $spacing-unit;
162 | padding-left: $spacing-unit;
163 | @extend %clearfix;
164 |
165 | @include media-query($on-laptop) {
166 | max-width: -webkit-calc(#{$content-width} - (#{$spacing-unit}));
167 | max-width: calc(#{$content-width} - (#{$spacing-unit}));
168 | padding-right: $spacing-unit / 2;
169 | padding-left: $spacing-unit / 2;
170 | }
171 | }
172 |
173 |
174 |
175 | /**
176 | * Clearfix
177 | */
178 | %clearfix {
179 |
180 | &:after {
181 | content: "";
182 | display: table;
183 | clear: both;
184 | }
185 | }
186 |
187 |
188 |
189 | /**
190 | * Icons
191 | */
192 | .icon {
193 |
194 | > svg {
195 | display: inline-block;
196 | width: 16px;
197 | height: 16px;
198 | vertical-align: middle;
199 |
200 | path {
201 | fill: $grey-color;
202 | }
203 | }
204 | }
205 |
--------------------------------------------------------------------------------
/_sass/_layout.scss:
--------------------------------------------------------------------------------
1 | /**
2 | * Site header
3 | */
4 | .site-header {
5 | border-top: 5px solid $grey-color-dark;
6 | border-bottom: 1px solid $grey-color-light;
7 | min-height: 56px;
8 |
9 | // Positioning context for the mobile navigation icon
10 | position: relative;
11 | }
12 |
13 | .site-title {
14 | font-size: 26px;
15 | line-height: 56px;
16 | letter-spacing: -1px;
17 | margin-bottom: 0;
18 | float: left;
19 |
20 | &,
21 | &:visited {
22 | color: $grey-color-dark;
23 | }
24 | }
25 |
26 | .site-nav {
27 | float: right;
28 | line-height: 56px;
29 |
30 | .menu-icon {
31 | display: none;
32 | }
33 |
34 | .page-link {
35 | color: $text-color;
36 | line-height: $base-line-height;
37 |
38 | // Gaps between nav items, but not on the first one
39 | &:not(:first-child) {
40 | margin-left: 20px;
41 | }
42 | }
43 |
44 | @include media-query($on-palm) {
45 | position: absolute;
46 | top: 9px;
47 | right: 30px;
48 | background-color: $background-color;
49 | border: 1px solid $grey-color-light;
50 | border-radius: 5px;
51 | text-align: right;
52 |
53 | .menu-icon {
54 | display: block;
55 | float: right;
56 | width: 36px;
57 | height: 26px;
58 | line-height: 0;
59 | padding-top: 10px;
60 | text-align: center;
61 |
62 | > svg {
63 | width: 18px;
64 | height: 15px;
65 |
66 | path {
67 | fill: $grey-color-dark;
68 | }
69 | }
70 | }
71 |
72 | .trigger {
73 | clear: both;
74 | display: none;
75 | }
76 |
77 | &:hover .trigger {
78 | display: block;
79 | padding-bottom: 5px;
80 | }
81 |
82 | .page-link {
83 | display: block;
84 | padding: 5px 10px;
85 | }
86 | }
87 | }
88 |
89 |
90 |
91 | /**
92 | * Site footer
93 | */
94 | .site-footer {
95 | border-top: 1px solid $grey-color-light;
96 | padding: $spacing-unit 0;
97 | }
98 |
99 | .footer-heading {
100 | font-size: 18px;
101 | margin-bottom: $spacing-unit / 2;
102 | }
103 |
104 | .contact-list,
105 | .social-media-list {
106 | list-style: none;
107 | margin-left: 0;
108 | }
109 |
110 | .footer-col-wrapper {
111 | font-size: 15px;
112 | color: $grey-color;
113 | margin-left: -$spacing-unit / 2;
114 | @extend %clearfix;
115 | }
116 |
117 | .footer-col {
118 | float: left;
119 | margin-bottom: $spacing-unit / 2;
120 | padding-left: $spacing-unit / 2;
121 | }
122 |
123 | .footer-col-1 {
124 | width: -webkit-calc(35% - (#{$spacing-unit} / 2));
125 | width: calc(35% - (#{$spacing-unit} / 2));
126 | }
127 |
128 | .footer-col-2 {
129 | width: -webkit-calc(20% - (#{$spacing-unit} / 2));
130 | width: calc(20% - (#{$spacing-unit} / 2));
131 | }
132 |
133 | .footer-col-3 {
134 | width: -webkit-calc(45% - (#{$spacing-unit} / 2));
135 | width: calc(45% - (#{$spacing-unit} / 2));
136 | }
137 |
138 | @include media-query($on-laptop) {
139 | .footer-col-1,
140 | .footer-col-2 {
141 | width: -webkit-calc(50% - (#{$spacing-unit} / 2));
142 | width: calc(50% - (#{$spacing-unit} / 2));
143 | }
144 |
145 | .footer-col-3 {
146 | width: -webkit-calc(100% - (#{$spacing-unit} / 2));
147 | width: calc(100% - (#{$spacing-unit} / 2));
148 | }
149 | }
150 |
151 | @include media-query($on-palm) {
152 | .footer-col {
153 | float: none;
154 | width: -webkit-calc(100% - (#{$spacing-unit} / 2));
155 | width: calc(100% - (#{$spacing-unit} / 2));
156 | }
157 | }
158 |
159 |
160 |
161 | /**
162 | * Page content
163 | */
164 | .page-content {
165 | padding: $spacing-unit 0;
166 | }
167 |
168 | .page-heading {
169 | font-size: 20px;
170 | }
171 |
172 | .post-list {
173 | margin-left: 0;
174 | list-style: none;
175 |
176 | > li {
177 | margin-bottom: $spacing-unit;
178 | }
179 | }
180 |
181 | .post-meta {
182 | font-size: $small-font-size;
183 | color: $grey-color;
184 | }
185 |
186 | .post-link {
187 | display: block;
188 | font-size: 24px;
189 | }
190 |
191 |
192 |
193 | /**
194 | * Posts
195 | */
196 | .post-header {
197 | margin-bottom: $spacing-unit;
198 | }
199 |
200 | .post-title {
201 | font-size: 42px;
202 | letter-spacing: -1px;
203 | line-height: 1;
204 |
205 | @include media-query($on-laptop) {
206 | font-size: 36px;
207 | }
208 | }
209 |
210 | .post-content {
211 | margin-bottom: $spacing-unit;
212 |
213 | h2 {
214 | font-size: 32px;
215 |
216 | @include media-query($on-laptop) {
217 | font-size: 28px;
218 | }
219 | }
220 |
221 | h3 {
222 | font-size: 26px;
223 |
224 | @include media-query($on-laptop) {
225 | font-size: 22px;
226 | }
227 | }
228 |
229 | h4 {
230 | font-size: 20px;
231 |
232 | @include media-query($on-laptop) {
233 | font-size: 18px;
234 | }
235 | }
236 | }
237 |
--------------------------------------------------------------------------------
/_sass/_syntax-highlighting.scss:
--------------------------------------------------------------------------------
1 | /**
2 | * Syntax highlighting styles
3 | */
4 | .highlight {
5 | background: #fff;
6 | @extend %vertical-rhythm;
7 |
8 | .c { color: #998; font-style: italic } // Comment
9 | .err { color: #a61717; background-color: #e3d2d2 } // Error
10 | .k { font-weight: bold } // Keyword
11 | .o { font-weight: bold } // Operator
12 | .cm { color: #998; font-style: italic } // Comment.Multiline
13 | .cp { color: #999; font-weight: bold } // Comment.Preproc
14 | .c1 { color: #998; font-style: italic } // Comment.Single
15 | .cs { color: #999; font-weight: bold; font-style: italic } // Comment.Special
16 | .gd { color: #000; background-color: #fdd } // Generic.Deleted
17 | .gd .x { color: #000; background-color: #faa } // Generic.Deleted.Specific
18 | .ge { font-style: italic } // Generic.Emph
19 | .gr { color: #a00 } // Generic.Error
20 | .gh { color: #999 } // Generic.Heading
21 | .gi { color: #000; background-color: #dfd } // Generic.Inserted
22 | .gi .x { color: #000; background-color: #afa } // Generic.Inserted.Specific
23 | .go { color: #888 } // Generic.Output
24 | .gp { color: #555 } // Generic.Prompt
25 | .gs { font-weight: bold } // Generic.Strong
26 | .gu { color: #aaa } // Generic.Subheading
27 | .gt { color: #a00 } // Generic.Traceback
28 | .kc { font-weight: bold } // Keyword.Constant
29 | .kd { font-weight: bold } // Keyword.Declaration
30 | .kp { font-weight: bold } // Keyword.Pseudo
31 | .kr { font-weight: bold } // Keyword.Reserved
32 | .kt { color: #458; font-weight: bold } // Keyword.Type
33 | .m { color: #099 } // Literal.Number
34 | .s { color: #d14 } // Literal.String
35 | .na { color: #008080 } // Name.Attribute
36 | .nb { color: #0086B3 } // Name.Builtin
37 | .nc { color: #458; font-weight: bold } // Name.Class
38 | .no { color: #008080 } // Name.Constant
39 | .ni { color: #800080 } // Name.Entity
40 | .ne { color: #900; font-weight: bold } // Name.Exception
41 | .nf { color: #900; font-weight: bold } // Name.Function
42 | .nn { color: #555 } // Name.Namespace
43 | .nt { color: #000080 } // Name.Tag
44 | .nv { color: #008080 } // Name.Variable
45 | .ow { font-weight: bold } // Operator.Word
46 | .w { color: #bbb } // Text.Whitespace
47 | .mf { color: #099 } // Literal.Number.Float
48 | .mh { color: #099 } // Literal.Number.Hex
49 | .mi { color: #099 } // Literal.Number.Integer
50 | .mo { color: #099 } // Literal.Number.Oct
51 | .sb { color: #d14 } // Literal.String.Backtick
52 | .sc { color: #d14 } // Literal.String.Char
53 | .sd { color: #d14 } // Literal.String.Doc
54 | .s2 { color: #d14 } // Literal.String.Double
55 | .se { color: #d14 } // Literal.String.Escape
56 | .sh { color: #d14 } // Literal.String.Heredoc
57 | .si { color: #d14 } // Literal.String.Interpol
58 | .sx { color: #d14 } // Literal.String.Other
59 | .sr { color: #009926 } // Literal.String.Regex
60 | .s1 { color: #d14 } // Literal.String.Single
61 | .ss { color: #990073 } // Literal.String.Symbol
62 | .bp { color: #999 } // Name.Builtin.Pseudo
63 | .vc { color: #008080 } // Name.Variable.Class
64 | .vg { color: #008080 } // Name.Variable.Global
65 | .vi { color: #008080 } // Name.Variable.Instance
66 | .il { color: #099 } // Literal.Number.Integer.Long
67 | }
68 |
--------------------------------------------------------------------------------
/about.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: page
3 | title: About
4 | permalink: /about/
5 | ---
6 |
7 | This is the base Jekyll theme. You can find out more info about customizing your Jekyll theme, as well as basic Jekyll usage documentation at [jekyllrb.com](http://jekyllrb.com/)
8 |
9 | You can find the source code for the Jekyll new theme at: [github.com/jglovier/jekyll-new](https://github.com/jglovier/jekyll-new)
10 |
11 | You can find the source code for Jekyll at [github.com/jekyll/jekyll](https://github.com/jekyll/jekyll)
12 |
--------------------------------------------------------------------------------
/css/layout.css:
--------------------------------------------------------------------------------
1 | a { color:#c06000 ;}
2 | a:hover, a:active { color:#f1362f ;}
3 |
4 | h1 > a,
5 | h1 > a:hover,
6 | h1 > a:active {
7 | color: inherit;
8 | text-decoration: none;
9 | }
10 | body {padding:0; margin:0; font-family: '나눔바른고딕',NanumBarunGothic,ng,'맑은 고딕','Malgun Gothic','돋움',Dotum,'애플 SD 산돌고딕 Neo','Apple SD Gothic Neo',AppleGothic,Helvetica,sans-serif; color:#444;}
11 | body > header {height:140px; background-color:#f8f8f8; padding:0; padding-top:30px; margin:0; margin-bottom: 50px; box-sizing:border-box;}
12 | body > header .logo h1 { display:inline-block; margin:0; padding:0; font-size: 28px; color:#78654e; font-weight: 200; line-height: 1.2;}
13 | body > header .logo h1 small {display:block; font-size:13px; color:#777;}
14 | body > header .logo img {width: 65px; display:inline-block; margin-right:8px;}
15 | body > header .btn_area {position:absolute; right:0; bottom:0px;}
16 | body > header .btn_area .button { display: inline-block;
17 | margin-left: 7px;
18 | height: 40px;
19 | line-height: 40px;
20 | padding: 0 20px;
21 | border: 2px solid #dedede;
22 | background:#fff;
23 | border-radius: 5px;
24 | text-decoration: none;
25 | color:#444;
26 | font-size: 14px; -webkit-transition: all .2s ease-in-out; -moz-transition: all .2s ease-in-out; -ms-transition: all .2s ease-in-out; -o-transition: all .2s ease-in-out; transition: all .2s ease-in-out;}
27 | body > header .btn_area .button:hover { background: #ffe;}
28 | .wrap {position:relative; width: 1080px; margin: 0 auto;}
29 |
30 | .content {float:right; width: 710px; padding-bottom:70px;}
31 | .content > *:first-child {margin-top:0; padding-top:10px; }
32 | .sidebar {float:left; width:230px; padding:20px 65px 20px 0; border-right:1px solid #ddd; color:#888;}
33 |
34 | /*.body .sidebar ul {margin:0; padding:0; list-style:none;}*/
35 | .body .sidebar div.title { color:#555555; font-size: 17px;}
36 | .body .sidebar ul { display: block; list-style: none; margin: 10px 0 0 0; padding: 10px 0 0 0; font-size: 14px;}
37 | .body .sidebar ul > li { font-size: 14px; line-height: 30px}
38 | .body .sidebar ul > li a {text-decoration: none}
39 | .body .sidebar ul > li img {padding-top:10px}
40 |
41 | .body .sidebar div.title + ul {
42 | margin-bottom: 40px;
43 | }
44 |
45 | p {line-height: 1.5; margin: 10px 0 15px; }
46 |
47 | code, kbd, pre, samp { font-family: source-code-pro, monospace; }
48 | p code,
49 | h2 code,
50 | h3 code,
51 | h4 code,
52 | h5 code,
53 | h6 code {
54 | background: #fff;
55 | border: 1px solid #DEDEDE;
56 | color: #333333;
57 | padding: 1px 5px;
58 | border-radius: 3px;
59 | }
60 |
61 |
62 | .docs article ul { font-size: 15px; }
63 | .docs article p { font-size: 15px; line-height: 1.8; }
64 | .docs article h1 + ul { margin: 0; padding: 0; list-style: none; font-size: 16px; font-weight: bold; line-height: 1.5; padding-bottom: 50px; border-bottom: 1px solid #f0f2f1; }
65 | .docs article h1 + ul li:before { content: "# "; margin-right: .25em; color: #78654e; opacity: .3; }
66 | .docs article h1 + ul li a {
67 | text-decoration: none;
68 | }
69 | .docs article h1 { font-size: 40px; font-weight: 200; }
70 | .docs article h2 {
71 | display:inline-block;
72 | font-size: 28px;
73 | font-weight: 400;
74 | position: relative;
75 | margin-bottom: 8px;
76 | }
77 | .docs article h2 a, .docs article h2 a:hover {
78 | color: #525252;
79 | text-decoration: none; }
80 | .docs article h2 a:after {
81 | content: "#";
82 | position: absolute;
83 | font-size: 28px;
84 | top: 1px;
85 | right: -25px;
86 | color: #78654e;
87 | opacity: .7; }
88 | .docs article h3 {
89 | font-size: 24px;
90 | font-weight: 400; }
91 | .docs article h4 {
92 | font-size: 16px;
93 | font-weight: 700; }
94 | .docs article a {
95 | text-decoration: underline; }
96 | .docs article a:hover {
97 | color: #f1362f; }
98 | .docs article blockquote a:hover {
99 | color: #fcd8d6; }
100 | .docs article table {
101 | border-collapse: collapse;
102 | width: 100%;
103 | font-size: 14px; }
104 | .docs article table th, .docs article table td {
105 | border: 1px solid #dee0df;
106 | padding: 10px;
107 | text-align: left; }
108 | .docs article table th {
109 | font-size: 16px; }
110 |
111 |
112 | blockquote {
113 | background: #f4645f;
114 | color: #fff;
115 | border-radius: 3px;
116 | margin: 10px 0 20px;
117 | padding: 10px 15px; }
118 | blockquote p:last-child {
119 | margin: 0; }
120 | blockquote a {
121 | color: #fff; }
122 |
123 |
124 | /* http://prismjs.com/download.html?themes=prism&languages=markup+css+clike+javascript+php */
125 | /**
126 | * prism.js default theme for JavaScript, CSS and HTML
127 | * Based on dabblet (http://dabblet.com)
128 | * @author Lea Verou
129 | */
130 |
131 | /* Code blocks */
132 | pre[class*="language-"] {
133 | padding: 1em;
134 | margin: 10px 0 20px;
135 | overflow: auto; }
136 |
137 | div.highlight pre {
138 | background: rgba(238, 238, 238, 0.35);
139 | border-radius: 3px;
140 | padding: 10px;
141 | box-shadow: 0 1px 1px rgba(0, 0, 0, 0.125); }
142 |
143 | /* Inline code */
144 | :not(pre) > code[class*="language-"] {
145 | background: #f0f2f1;
146 | color: #f4645f;
147 | padding: 1px 5px;
148 | border-radius: 3px; }
149 |
150 | .token.comment, .token.prolog, .token.doctype, .token.cdata {
151 | color: #999; }
152 |
153 | .token.punctuation {
154 | color: #999; }
155 |
156 | .namespace {
157 | opacity: .7; }
158 |
159 | .token.property, .token.tag, .token.boolean, .token.number, .token.constant, .token.symbol, .token.deleted {
160 | color: #DA564A; }
161 |
162 | .token.scope, .token.attr-name {
163 | color: #DA564A; }
164 |
165 | .token.selector, .token.string, .token.char, .token.builtin, .token.inserted {
166 | color: #2E7D32; }
167 |
168 | .token.operator, .token.entity, .token.url, .language-css .token.string, .style .token.string {
169 | color: #555; }
170 |
171 | .token.atrule, .token.attr-value, .token.keyword {
172 | color: #07a; }
173 |
174 | .token.function {
175 | color: #555; }
176 |
177 | .token.regex, .token.important, .token.variable {
178 | color: #4EA1DF; }
179 |
180 | .token.important, .token.bold {
181 | font-weight: bold; }
182 |
183 | .token.italic {
184 | font-style: italic; }
185 |
186 | .token.entity {
187 | cursor: help; }
188 |
189 | pre.line-numbers {
190 | position: relative;
191 | padding-left: 3.8em;
192 | padding-top: 0px;
193 | margin-top: -1px;
194 | border-radius: 0;
195 | counter-reset: linenumber; }
196 |
197 | pre.line-numbers > code {
198 | position: relative; }
199 |
200 | .line-numbers .line-numbers-rows {
201 | position: absolute;
202 | pointer-events: none;
203 | top: -2px;
204 | padding-top: 2px;
205 | font-size: 100%;
206 | left: -3.8em;
207 | width: 3em;
208 | /* works for line-numbers below 1000 lines */
209 | letter-spacing: -1px;
210 | background: #f0f2f1;
211 | -webkit-user-select: none;
212 | -moz-user-select: none;
213 | -ms-user-select: none;
214 | user-select: none; }
215 |
216 | .line-numbers-rows > span {
217 | pointer-events: none;
218 | display: block;
219 | counter-increment: linenumber; }
220 |
221 | .line-numbers-rows > span:before {
222 | content: counter(linenumber);
223 | color: #999;
224 | display: block;
225 | padding-right: 0.8em;
226 | text-align: right; }
227 |
228 | .dark-code {
229 | /* Code blocks */
230 | /* Inline code */ }
231 | .dark-code code[class*="language-"], .dark-code pre[class*="language-"] {
232 | color: #f8f8f2;
233 | text-shadow: 0 1px rgba(0, 0, 0, 0.3);
234 | font-family: Consolas, Monaco, 'Andale Mono', monospace;
235 | direction: ltr;
236 | text-align: left;
237 | white-space: pre;
238 | word-spacing: normal;
239 | word-break: normal;
240 | line-height: 1.5;
241 | -moz-tab-size: 4;
242 | -o-tab-size: 4;
243 | tab-size: 4;
244 | -webkit-hyphens: none;
245 | -moz-hyphens: none;
246 | -ms-hyphens: none;
247 | hyphens: none; }
248 | .dark-code pre[class*="language-"] {
249 | padding: 1em;
250 | margin: .5em 0;
251 | overflow: auto;
252 | border-radius: 0.3em; }
253 | .dark-code :not(pre) > code[class*="language-"], .dark-code pre[class*="language-"] {
254 | background: #272822; }
255 | .dark-code :not(pre) > code[class*="language-"] {
256 | padding: .1em;
257 | border-radius: .3em; }
258 | .dark-code .token.comment, .dark-code .token.prolog, .dark-code .token.doctype, .dark-code .token.cdata {
259 | color: slategray; }
260 | .dark-code .token.punctuation {
261 | color: #f8f8f2; }
262 | .dark-code .namespace {
263 | opacity: .7; }
264 | .dark-code .token.property, .dark-code .token.tag, .dark-code .token.constant, .dark-code .token.symbol, .dark-code .token.deleted {
265 | color: #f92672; }
266 | .dark-code .token.boolean, .dark-code .token.number {
267 | color: #ae81ff; }
268 | .dark-code .token.selector, .dark-code .token.attr-name, .dark-code .token.string, .dark-code .token.char, .dark-code .token.builtin, .dark-code .token.inserted {
269 | color: #a6e22e; }
270 | .dark-code .token.operator, .dark-code .token.entity, .dark-code .token.url, .dark-code .language-css .token.string, .dark-code .style .token.string, .dark-code .token.variable {
271 | color: #f8f8f2; }
272 | .dark-code .token.atrule, .dark-code .token.attr-value {
273 | color: #e6db74; }
274 | .dark-code .token.keyword {
275 | color: #66d9ef; }
276 | .dark-code .token.regex, .dark-code .token.important {
277 | color: #fd971f; }
278 | .dark-code .token.important, .dark-code .token.bold {
279 | font-weight: bold; }
280 | .dark-code .token.italic {
281 | font-style: italic; }
282 | .dark-code .token.entity {
283 | cursor: help; }
--------------------------------------------------------------------------------
/css/main.scss:
--------------------------------------------------------------------------------
1 | ---
2 | # Only the main Sass file needs front matter (the dashes are enough)
3 | ---
4 | @charset "utf-8";
5 |
6 |
7 |
8 | // Our variables
9 | $base-font-family: Helvetica, Arial, sans-serif;
10 | $base-font-size: 16px;
11 | $small-font-size: $base-font-size * 0.875;
12 | $base-line-height: 1.5;
13 |
14 | $spacing-unit: 30px;
15 |
16 | $text-color: #111;
17 | $background-color: #fdfdfd;
18 | $brand-color: #2a7ae2;
19 |
20 | $grey-color: #828282;
21 | $grey-color-light: lighten($grey-color, 40%);
22 | $grey-color-dark: darken($grey-color, 25%);
23 |
24 | // Width of the content area
25 | $content-width: 800px;
26 |
27 | $on-palm: 600px;
28 | $on-laptop: 800px;
29 |
30 |
31 |
32 | // Using media queries with like this:
33 | // @include media-query($on-palm) {
34 | // .wrapper {
35 | // padding-right: $spacing-unit / 2;
36 | // padding-left: $spacing-unit / 2;
37 | // }
38 | // }
39 | @mixin media-query($device) {
40 | @media screen and (max-width: $device) {
41 | @content;
42 | }
43 | }
44 |
45 |
46 |
47 | // Import partials from `sass_dir` (defaults to `_sass`)
48 | @import
49 | "base",
50 | "layout",
51 | "syntax-highlighting"
52 | ;
53 |
--------------------------------------------------------------------------------
/doc/00-intro.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "소개하기"
4 | permalink: /doc/00-intro.md/
5 | ---
6 |
7 | # 소개하기
8 |
9 | 컴포저는 PHP 에서 의존성을 관리하기 위한 툴입니다. 컴포저는 프로젝트를 위한 라이브러리들을 선언하고 의존성이 있는 라이브러리들을 설치할 수 있게 해줍니다.
10 |
11 | ## 의존성 관리
12 |
13 | 컴포저는 패키지 관리자가 아닙니다. 컴포저는 "패키지" 또는 라이브러리를 처리하긴 하지만 프로젝트 단위로 디렉토리에 설치하는 것을 책임집니다. (예를들어 `vendor` 디렉토리) 기본적으로 컴포저는 어떠한 것도 글로벌로 설치하지 않습니다. 따라서 컴포저는 그 자체로 의존성 관리자라고 할 수 있습니다.
14 |
15 | 컴포저는 node.js 의 [npm](http://npmjs.org/)과 ruby의 [bundler](http://gembundler.com/)에 영감을 받았습니다. 이런 아이디어는 그다지 새롭지 않습니다만 이전까지 PHP 에서는 이러한 툴이 존재하지 않았습니다.
16 |
17 | 컴포저가 할 수 있는 일들은 다음과 같습니다:
18 |
19 | a) 여러 라이브러리에 의존하는 프로젝트를 가지고 있습니다.
20 |
21 | b) 이러한 라이브러리들은 또다른 라이브러리들을 필요로 합니다.
22 |
23 | c) 이때 여러분이 필요로 하는 의존 관계의 라이브러리들을 지정해 줄수 있습니다.
24 |
25 | d) 컴포저는 패키지가 설치되어야하는 버전을 찾아, 알맞은 버전의 패키지들과 의존 패키지들을 설치합니다 (프로젝트 디렉토리로 다운로드 한다는 의미입니다).
26 |
27 | ## 의존성 선언 {#declaring-dependencies}
28 |
29 | 새로운 프로젝트를 생성하고 로깅을 위한 라이브러리가 필요하다고 생각해 봅시다. 이 때 [monolog](https://github.com/Seldaek/monolog)를 사용하기로 했다고 합시다. 이 라이브러리를 프로젝트에 추가하기 위해서는 다음과 같이 `composer.json`을 생성하고 여기 에 프로젝트의 의존성을 선언하면 됩니다.
30 |
31 | {% highlight json %}
32 | {
33 | "require": {
34 | "monolog/monolog": "1.2.*"
35 | }
36 | }
37 | {% endhighlight %}
38 |
39 | 이렇게 프로젝트에서 `1.2`로 시작하는 `monolog/monolog` 패키지가 필요하다는 것을 간단하게 표시할 수 있습니다.
40 |
41 | ## 시스템 요구사항
42 |
43 | 컴포저는 PHP 5.3.2+ 이상에서 동작합니다. 몇가지 민감한 PHP 설정을 필요로 하지만 인스톨러를 사용하면 이러한 비호환성을 체크하고 경고를 확인할 수 있습니다.
44 |
45 | 소스로 부터 패키지를 인스톨하기 위해서 zip파일을 다운받는 대신에 패키지가 관리되고 있는 git, svr 또는 hg 와 같은 버전관리 시스템을 사용할 수 있습니다.
46 |
47 | 컴포저는 멀티 플랫폼을 지원하며 윈도우(Windows), 리눅스(Linux) 그리고 맥OSX(OSX)에서 동일하게 동작합니다.
48 |
49 | ## 설치방법 - Linux / Unix / OSX
50 |
51 | ### 컴포저실행파일을 다운로드 하는 방법
52 |
53 | 간단하게 말하자면 컴포저를 인스톨 하는 데는 두가지 방법이 있습니다. 로컬 프로젝트에 인스톨 하는 방법과 시스템에 설치하여 실행가능하게 하는 글로벌 설치가 있습니다.
54 |
55 | #### 로컬 설치
56 |
57 | 로컬 설치를 하기 위해서는 프로젝트 디렉토리에서 다음과 같이 인스톨러를 실행하면 됩니다. :
58 |
59 | {% highlight sh %}
60 | curl -sS https://getcomposer.org/installer | php
61 | {% endhighlight %}
62 |
63 | > **주의:** 만약 위의 방법이 실패한다면 `php`를 앞에 붙여 인스톨러를 다운로드 하는 방법을 시도해 볼 수 있습니다.
64 |
65 | {% highlight sh %}
66 | php -r "readfile('https://getcomposer.org/installer');" | php
67 | {% endhighlight %}
68 |
69 | 인스톨러는 몇가지의 PHP 셋팅을 확인한 다음에 `composer.phar` 파일을 현재 디렉토리에 다운로드 합니다. 이 파일이 바로 컴포저 실행파일입니다. 이 파일은 커맨드 라인에서 실행할 수 있는 PHP 아카이브 포맷인 PHAR 로 되어 있습니다.
70 |
71 | 만약 설치하고자 하는 디렉토리가 다르다면 `--install-dir` 옵션을 사용하여 원하는 설치 디렉토리를 설정할 수도 있습니다. (경로는 절대경로와 상대경로로 지정합니다.)
72 |
73 | {% highlight sh %}
74 | curl -sS https://getcomposer.org/installer | php -- --install-dir=bin
75 | {% endhighlight %}
76 |
77 | #### 글로벌 설치 {#globally}
78 |
79 | 설치된 컴포저 파일은 그 어디라도 쉽게 옮길 수 있습니다. 만약 파일을 `PATH`에 설정된 곳에 넣는다면 어디서라도 실행이 가능해집니다. 유닉스 시스템이라면 `php`를 붙이지 않더라도 바로 실행할 수 있습니다.
80 |
81 | 다음 스크립트를 실행시키면 시스템 어디서라도 `composer` 라는 명령어를 통해서 실행할 수 있게 됩니다.
82 |
83 | {% highlight sh %}
84 | curl -sS https://getcomposer.org/installer | php
85 | mv composer.phar /usr/local/bin/composer
86 | {% endhighlight %}
87 |
88 | > **주의:** `mv` 명령어를 실행하는데는 권한이 필요하다면 sudo 와 함께 실행하시기 바랍니다.
89 |
90 | 이제 `php composer.phar` 대신 `composer` 로 간단하게 컴포저를 구동 할 수 있습니다.
91 |
92 | ## 윈도우에서의 설치
93 |
94 | ### 인스톨러를 사용한 방법
95 |
96 | 이 방법은 윈도우에서 컴포저를 설치하는 가장 손쉬운 방법입니다.
97 |
98 | 다음의 파일을 다운 받고 실행합니다. [Composer-Setup.exe](https://getcomposer.org/Composer-Setup.exe),
99 | 이 인스톨러는 최신 버전의 컴포저를 설치하고 PATH를 지정하여 커맨드라인에서 언제라도 `composer`명령어를 입력해 프로그램이 실행될 수 있게 해줍니다.
100 |
101 | > **주의:** 설치후에는 현재 터미널을 닫고, 새로운 터미널에서 명령어를 테스트해 보시길 바랍니다:
102 | > 왜냐하면 PATH 설정은 터미널이 시작할 때만 새롭게 감지하기 때문입니다.
103 |
104 | ### 수동 설치
105 |
106 | 디렉토리를 `PATH`에 설정된 디렉토리로 변경하고 다음의 스크립트를 실행해 composer.phar 을 다운로드 합니다.
107 |
108 | {% highlight sh %}
109 | C:\Users\username>cd C:\bin
110 | C:\bin>php -r "readfile('https://getcomposer.org/installer');" | php
111 | {% endhighlight %}
112 |
113 | > **주의:** 만약 readfile 스크립트가 실패한다면 `http` URL 을 이용하거나, php.ini 파일에서 php_openssl.dll 를 활성화 하십시오.
114 |
115 | 그다음에 `composer.phar` 파일 옆에 `composer.bat` 파일을 만듭니다:
116 |
117 | {% highlight sh %}
118 | C:\bin>echo @php "%~dp0composer.phar" %*>composer.bat
119 | {% endhighlight %}
120 |
121 | 현재의 터미널을 종료하고, 새로운 터미널에서 다음의 명령어를 테스트 해봅니다.
122 |
123 |
124 | {% highlight sh %}
125 | C:\Users\username>composer -V
126 | Composer version 27d8904
127 | {% endhighlight %}
128 |
129 | ## 컴포저 사용하기
130 |
131 | 이제 프로젝트의 의존성 관리를 위해 컴포저를 통해 패키지 설치를 해 보겠습니다. 현재 디렉토리에 `composer.json` 파일을 가지고 있지 않다면 먼저
132 | [기본사용법](/Composer-korean-docs/doc/01-basic-usage.md) 챕터를 확인하시기 바랍니다.
133 |
134 | 의존성 패키지들을 다운로드 하기 위해서는 `install` 명령어를 사용합니다:
135 |
136 | {% highlight sh %}
137 | php composer.phar install
138 | {% endhighlight %}
139 |
140 | 글로벌 설치를 진행하였고, phar 확장자를 가지고 있지 않다면 다음처럼 해도 됩니다.
141 |
142 | {% highlight sh %}
143 | composer install
144 | {% endhighlight %}
145 |
146 | [의존성 선언](#declaring-dependencies)에서와 같이 설정되어 있다면, 이 명령어를 통해서 monolog 를 다운로드 하여 `vendor/monolog/monolog` 라는 디렉토리를 생성하게 됩니다.
147 |
148 | ## 오토로딩
149 |
150 | 라이브러리를 다운로드 하는 것과 함께 컴포저는 다운로드 된 어떤 라이브러리의 모든 클래스를 자동으로 불러 올 수 있도록 하는 오토로딩 파일을 준비하게 됩니다. 오토로딩을 사용하기 위해서는 다음처럼 코드의 부트스트랩 과정을 거쳐야 합니다.
151 |
152 | {% highlight php %}
153 | require 'vendor/autoload.php';
154 | {% endhighlight %}
155 |
156 | 이제! monolog 를 바로 사용할 수 있습니다.! 컴포저에 대한 더 자세한 내용은 "기본 사용법" 챕터를 확인하시기 바랍니다.
157 |
158 | [기본 사용법](/Composer-korean-docs/doc/01-basic-usage.md) →
--------------------------------------------------------------------------------
/doc/01-basic-usage.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "기본 사용법"
4 | permalink: /doc/01-basic-usage.md/
5 | ---
6 |
7 | # 기본 사용법
8 |
9 | ## 설치하기
10 |
11 | 아직 컴포저를 설치하지 않았다면, [소개](/Composer-korean-docs/doc/00-intro.md) 챕터를 참고하시기 바랍니다.
12 |
13 | ## `composer.json`: 프로젝트 셋업
14 |
15 | 프로젝트에서 컴포저를 사용하기 위해서 필요한 것은 모두 `composer.json`파일에 있습니다. 이파일은 프로젝트의 의존성과 함께 많은 메타정보를 담고 있습니다.
16 |
17 | [JSON 포맷](http://json.org/)은 중첩된 구조를 정의하고 작성하는데 매우 쉬운 포맷입니다.
18 |
19 | ### `require` key
20 |
21 | `composer.json`에서 처음으로 살펴볼 것은 매번 확인하게 되는 `require`키입니다. 이 키는 컴포저에게 프로젝트가 어떤 패키지들을 필요로 하는지 알려줍니다.
22 |
23 | {% highlight json %}
24 | {
25 | "require": {
26 | "monolog/monolog": "1.0.*"
27 | }
28 | }
29 | {% endhighlight %}
30 |
31 | 보시는 바와 같이 `require` 는 **패키지 이름** (e.g. `monolog/monolog`)
32 | 과 **패키지 버전** (e.g. `1.0.*`)의 맵핑 형태로 된 객체들로 표현됩니다.
33 |
34 | ### 패키지 이름
35 |
36 | 패키지 이름은 벤더의 이름과 프로젝트의 이름으로 구성되어져 있습니다. 벤더 이름은 동일한 패키지 이름을 충돌을 방지하기 위해서 존재합니다(종종 동일한 패키지가 존재할 수 있습니다). 만약 각각 다른 두명의 사람이 `json`이라는 라이브러리를 만들더라도, 둘다 `igorw/json` 그리고 `seldaek/json`와 같이 구분하여 사용할 수 있게 해줍니다.
37 |
38 | 위에서 예시로든 `monolog/monolog`의 경우에는 벤더의 이름과 패키지 이름이 동일한 경우 입니다. 프로젝트가 하나만 존재하는 경우에는 이렇게 구성하는것이 권장됩니다. 또한 나중에 관련된 프로젝트를 동일한 이름에 더 추가할 수도 있습니다. 만약 라이브러리를 유지 보수한다면, 더 작은 부분들로 이루어 질 수 있도록 손쉽게 분리 할 수 있습니다.
39 |
40 | ### 패키지 버전 {#package-versions}
41 |
42 | 이전 예제에서 monolog 의 `1.0.*` 버전을 필요로 하다고 설정했습니다. 이 의미는 어떠한 `1.0` 브랜치도 가능하다는 뜻입니다. 따라서 버전이 `1.0.0`이 될수도 `1.0.2` 또는 `1.0.20`이 될수도 있습니다.
43 |
44 | 버전의 표시는 몇가지 다른 방법으로 지정할 수 있습니다.
45 |
46 | 이름 | 예제 | 설명
47 | -------------- | ------------------------------------------------------------------------ | -----------
48 | 정확한 버전 | `1.0.2` | 해당 패키지의 정확한 버전을 지정할 수 있습니다.
49 | 범위지정 | `>=1.0` `>=1.0 <2.0` >=1.0 <1.1 || >=1.2 | 비교구문을 사용하여 일정한 범위내의 버전을 지정할 수 있습니다. 사용 가능한 연산자는 `>`, `>=`, `<`, `<=`, `!=` 입니다. 여러 범위를 지정할 수도 있습니다. 범위지정은 스페이스로 구분되어 지거나 () **AND** 의미로 처리되는 콤마로 (`,`) 구분할 수도 있습니다. 두개의 파이프 기호는 (||) **OR**로 처리됩니다. AND 가 OR 에 우선하는 처리순서를 가집니다.
50 | 하이픈 범위지정 | `1.0 - 2.0` | 버전의 포괄적인 지정을 의미합니다. 오른쪽에 기입한 버전은 와일드카드로 표현되는 버전을 포함함을 의미합니다. 예를 들어 `1.0 - 2.0` 라는 표현은 `>=1.0.0 <2.1` 와 동일한데 오른쪽에 기입한 `2.0` 은 `2.0.*`의 의미가 됩니다. 다른 표현으로 `1.0.0 - 2.1.0` 는 `>=1.0.0 <=2.1.0`과 동일합니다.
51 | 와일드카드 | `1.0.*` | 버전을 `*` 의 와일드카드를 포함한 형태로 입력할 수 있습니다. `1.0.*` 는 `>=1.0 <1.1`과 동일한 의미를 나타냅니다.
52 | 물결표 표시 | `~1.2` | 이 표현은 프로젝트에 있어서 매우 유용한 표현입니다. `~1.2`는 `>=1.2 <2.0`와 동일한 의미를 가집니다. 좀더 자세한 설명은 다음 섹션을 참고하십시오.
53 | 삽입기호(^) 표시 | `^1.2.3` | 이 표현또한 프로젝트의 버전을 표시하는데 매우 유용합니다. `^1.2.3` 은 `>=1.2.3 <2.0`와 동일한 의미를 나타냅니다. 더 자세한 내용은, 다음 섹션을 참고하십시오.
54 |
55 | ### 다음 주요 릴리즈 (물결표 와 삽입기호(^)표현)
56 |
57 | `~` 물결표 표현은 예를 들어서 보는것이 제일 좋습니다. `~1.2`은 `>=1.2 <2.0.0`와 동일하고, `~1.2.3`은 `>=1.2.3 <1.3.0`와 의미가 같습니다. 이러한 표현은 [시멘틱 버저닝](http://semver.org/)을 따르는 프로젝트에 있어서 매우 유용합니다. 일반적으로 `~1.2`와 같이 최소버전을 표시하는 형식으로 사용되어집니다. (이상의 버전을 의미하지만 2.0 버전을 포함하지는 않음). 이러한 버저닝이 유지되려면 2.0 버전 이전까지는 호환성에 아무런 문제가 없어야 합니다. 위에서 보다시피 `~` 을 사용해서 최소버전을 지정하면, 지정된 마지막 자리까지만 허용하게 됩니다.
58 |
59 | `^` 삽입기호 표현은 시멘틱 버저닝의 표현과 비슷하게 동작하지만 다른 형태의 업데이트까지 허용합니다. 예를 들면 `^1.2.3`은 2.0 버전 미만의 호환성을 유지하는 `>=1.2.3 <2.0.0` 까지를 의미합니다. 또한 `^0.3`은 `>=0.3.0 <0.4.0`과 동일한 의미를 지닙니다.
60 |
61 | > **주의:** 비록 `2.0-beta.1`은 엄밀히 말해서 `2.0` 이전 버전이라고 할 수 있지만
62 | > `~1.2`으로 표시되었을 때 이버전을 설치하지는 않습니다. 다시말해서 `~1.2` 는 `.2` 버전만을 의미합니다.
63 | > 뒤의 버전은 변경될 수 있지만 `1.` 부분은 고정된 형식입니다.
64 |
65 | > **주의:** `~` 물결표 표현은 메이저 릴리즈 버전을 표시할 때 예외적으로 동작합니다.
66 | > 이 말은 `~1` 으로 표현한 버전은 `~1.0`과 동일한 의미를 가지며
67 | > 메이저 릴리즈가 업데이트 되기 전까지의 버전을 지칭한다고 할 수 있습니다.
68 |
69 | ### Stability 버전 안정성
70 |
71 | 기본적으로 버전 표시의 고려대상으로은 안정화 버전(stable)만을 의미합니다. 만약 RC, 베타, 알파 또는 개발 버전과 같은 표현이 필요하다면 [안정성 표시기호](/Composer-korean-docs/doc/04-schema.md#package-links)를 참고하십시오. 패키지의 의존성을 표시하는데 이러한 안정성 표현이 필요하다면 [최소 안정성](/Composer-korean-docs/doc/04-schema.md#minimum-stability) 셋팅을 참고하십시오.
72 |
73 | ## 의존 패키지 설치하기
74 |
75 | 의존관계가 선언된 패키지들을 로컬 프로젝트로 다운받기 위해서는 다음과 같이 `composer.phar`의 `install` 명령어를 입력하면 됩니다.
76 |
77 | {% highlight sh %}
78 | php composer.phar install
79 | {% endhighlight %}
80 |
81 | 이 명령어를 입력하면 `monolog/monolog` 패키지의 매칭 되는 가장 최신버전을 `vendor`디렉토리에 다운로드 받습니다.
82 | `vendor` 디렉토리는 서드파티의 패키지들이 다운로드 되는 폴더를 의미합니다. 위에서 살펴본 monolog 경우에는 `vendor/monolog/monolog`에 다운로드 됩니다.
83 |
84 | > **참고:** 프로젝트를 git으로 관리하고 있는 경우에 모든 서드파티의 코드가 추가되길 원하지 않는다면 `vendor` 디렉토리를 `.gitignore`에 추가하여 관리하면 됩니다.
85 |
86 | `install` 명령어를 통해서 의존관계가 설정된 패키지들 설치한 후에는 `composer.lock`파일이 프로젝트 루트 디렉토리에 생성됩니다.
87 |
88 | ## `composer.lock` - 잠금 설정 파일
89 |
90 | 의존성 패키지들을 설치한 뒤에 컴포저는 `composer.lock`파일에 설치한 패키지들의 정확한 버전 목록을 저장합니다. 이 잠금설정들이 프로젝트가 필요로 하는 특정 버전들을 의미합니다.
91 |
92 | **어플리케이션의 `composer.lock`파일을 (`composer.json`파일과 함께) VCS 플 통해서 커밋하십시오. **
93 |
94 | `install`명령어는 이 잠금파일이 디렉토리에 존재하는지 확인하고 만약 그렇다면 (`composer.json`에 관계없이) 잠금설정된 버전의 패키지들을 다운받습니다.
95 |
96 | 이것이 의미하는 것은 프로젝트를 셋업하고 의존성 패키지들을 다운로드 하려고 하는 그 어떤 누구라도 동일한 버전의 의존 패키지들을 다운로드 한다는 것을 의미합니다. CI서버, 실제의 제품 서버, 같은 팀내의 다른 개발자 모두가 동일한 의존성기반하에 프로젝트를 구동한 다는 것은 배포를 비롯한 일부 패키지들에 영향을 미치는 버그에 대한 가능성을 완화시켜 준다는 것을 의미합니다. 혹시나 혼자서 개발할지라도 6개월만에 다시 인스톨해야하는 프로젝트의 경우 그동안 의존성 패키지들의 새로운 버전이 나왔더라도 동일하게 작동하는 의존 패키지들을 다운로드 받을 수 있다는 것을 말합니다.
97 |
98 | 만약 `composer.lock` 파일이 존재하지 않는다면 컴포저는 `composer.json`의로 부터 의존성과 버전 정보를 읽어 들여 `update` 명령어나 `install`명령이 실행된 이후에 lock 파일을 생성합니다.
99 |
100 | 이 말은 어떤 새로운 의존성 패키지가 새롭게 업데이트 되더라도 자동으로 업데이트 할 수 없다는 것을 의미합니다. 새로운 버전으로 업데이트 받기 위해서는 `update` 명령어를 사용합니다. 그렇게 하면 버전에 알맞는(`composer.json` 파일에 맞는) 최신의 패키지를 업데이트 하고 lock 파일을 새롭게 생성하게 됩니다.
101 |
102 | {% highlight sh %}
103 | php composer.phar update
104 | {% endhighlight %}
105 | > **주의:** 컴포저는 `composer.lock` 파일과 `composer.json` 파일의 정보가 동기화 되어 있지 않다면 `install`명령어 수행시 경고를 표시합니다.
106 |
107 | 만약 하나의 의존 패키지들을 설치하거나 업데이트 하고자 한다면 다음처럼 각각의 패키지들을 나열하여 실행할 수 있습니다.
108 |
109 | {% highlight sh %}
110 | php composer.phar update monolog/monolog [...]
111 | {% endhighlight %}
112 |
113 | > **주의:** 라이브러리에는 lock 파일을 커밋하는 것이 불필요 합니다 .
114 | > 보다 자세한 사항은: [Libraries - Lock file](/Composer-korean-docs/doc/02-libraries.md#lock-file)을 참고하십시오.
115 |
116 | ## Packagist - 패키지스트
117 |
118 | [Packagist](https://packagist.org/)는 주요한 컴포저 저장소입니다. 컴포저 저장소란 기본적으로 패키지를 얻을 수 있는 곳을 의미합니다. 패키지스트는 모두가 사용할 수 있는 중앙저장소가 되는 것을 목표로 하고 있는데, 이 말은 즉 패키지스트에 올라와 있는 모든 패키지들은 `require` 할 수 있다는 것을 의미합니다.
119 |
120 | [패키지스트 웹사이트](https://packagist.org/) (packagist.org)에 접속하면, 패키지들에 대해서 검색하고 상세한 정보를 확인할 수 있습니다.
121 |
122 | 컴포저를 사용하는 오픈소스 프로젝트라면 컴포저를 통해서 프로젝트를 패키지스트에 게시하는 것이 좋습니다. 라이브러리 타입의 경우에는 꼭 패키지스트에 있을 필요는 없지만 그렇게 하는 것이 좀 더 사용을 쉽게 할 수 있습니다.
123 |
124 | ## Autoloading - 오토로딩
125 |
126 | 컴포저는 라이브러리들에 대한 오토로딩 정보를 `vendor/autoload.php` 파일에 저장합니다. 이 파일을 include 함으로써 오도로딩을 손쉽게 적용할 수 있습니다.
127 |
128 | {% highlight php %}
129 | require 'vendor/autoload.php';
130 | {% endhighlight %}
131 |
132 | 이렇게 함으로써 서드파티의 코드를를 사용하는 것을 아주 쉽게 만들어 줍니다. 예를 들어 : 작성하고 있는 프로젝트가 monolog 에 의존성을 가지고 있을 때 오토로딩을 사용하면 바로 해당 클래스를 사용할 수 있다는 것을 의미합니다.
133 |
134 | {% highlight php %}
135 | $log = new Monolog\Logger('name');
136 | $log->pushHandler(new Monolog\Handler\StreamHandler('app.log', Monolog\Logger::WARNING));
137 | $log->addWarning('Foo');
138 | {% endhighlight %}
139 |
140 | 오토로딩의 설정은 `composer.json` 의 `autoload` 설정을 통해서도 할 수 있습니다.
141 |
142 | {% highlight json %}
143 | {
144 | "autoload": {
145 | "psr-4": {"Acme\\": "src/"}
146 | }
147 | }
148 | {% endhighlight %}
149 |
150 | 위의 경우 컴포저는 `Acme` 네임스페이스를 [PSR-4](http://www.php-fig.org/psr/psr-4/)에 따라서 오토로딩을 설정합니다. 오토로딩은 네임스페이스에 대한 디렉토리 매핑을 정의합니다. `src` 디렉토리는 `vendor` 디렉토리와 마찬가지로 프로젝트 루트 디렉토리에 존재합니다. 예를 들어 `src/Foo.php` 파일은 `Acme\Foo` 클래스를 의미합니다.
151 |
152 | `autoload` 항목을 추가한 뒤에는 `dump-autoload` 명령어를 실행하여 `vendor/autoload.php` 파일을 재생성 해주어야 합니다.
153 |
154 | autoload.php 파일을 include 하게 되면 오토로더 인스턴스를 리턴 받을 수 있습니다. 이 리턴받은 인스턴스를 통해서 추가적인 네임스페이스를 지정할 수도 있습니다. 테스트가 필요한 경우 다음 예제처럼 유용하게 사용할 수 있습니다.
155 |
156 | {% highlight php %}
157 | $loader = require 'vendor/autoload.php';
158 | $loader->add('Acme\\Test\\', __DIR__);
159 | {% endhighlight %}
160 |
161 | PSR-4 오토로딩 이외에도 classmap 형태의 오토로딩도 지원합니다. 이 경우 PSR-4 형식에 맞지 않더라도 클래스를 오토로딩할 수 있습니다. 보다 자세한 정보는 [autoload reference](/Composer-korean-docs/doc/04-schema.md#autoload)을 참고하십시오.
162 |
163 | > **주의:** 컴포저는 자체적인 오토로더를 제공합니다. 컴포저의 자체적인 오토로더를 사용하지 않는 경우 연관된 배열을 리턴하게끔 구성된 `vendor/composer/autoload_*.php` 파일들을 include 하여 고유한 오토로더를 구성할 수 도 있습니다.
164 |
165 | ← [Intro](/Composer-korean-docs/doc/00-intro.md) | [Libraries](/Composer-korean-docs/doc/02-libraries.md) →
166 |
--------------------------------------------------------------------------------
/doc/02-libraries.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "Libraries - 라이브러리"
4 | permalink: /doc/02-libraries.md/
5 | ---
6 |
7 | # Libraries - 라이브러리
8 |
9 | 이번 챕터에서는 컴포저를 사용해서 라이브러리를 설치하는 방법에대해 설명하겠습니다.
10 |
11 | ## 모든 프로젝트는 패키지입니다
12 |
13 | 디렉토리에 `composer.json`이 존재하면 그 디렉토리는 패키지라는 것을 의미합니다. 프로젝트 컴포저에 `require`를 추가하게 되면 다른 패키지들에 의존성이 있는 패키지를 만들수 있습니다. 프로젝트와 라이브러리들의 차이는 단지 프로젝트는
14 | 이름을 가지지 않은 패키지라는것 뿐입니다.
15 |
16 |
17 | 패키지가 설치가능한 형태로 만들기 위해서는 이름이 필요한데, `composer.json` 에 `name` 를 추가하면 됩니다.
18 |
19 | {% highlight json %}
20 | {
21 | "name": "acme/hello-world",
22 | "require": {
23 | "monolog/monolog": "1.0.*"
24 | }
25 | }
26 | {% endhighlight %}
27 |
28 | In this case the project name is `acme/hello-world`, where `acme` is the
29 | vendor name. Supplying a vendor name is mandatory.
30 |
31 | 이 예제에서 프로젝트의 이름은 `acme/hello-world`이고 `acme`은 벤더 이름이됩니다. 벤더의 이름은 항상 존재해야 합니다.
32 |
33 | > **주의:** 만약 벤더 이름을 어떻게 정해야 할지 모르겠다면 보통은 github의 유저네임을 이용한다는 점을 참고합니다. 패키지의 이름은 대소문자를 구별하지 않고 모두 소문자를 사용하고 대쉬로 단어들을 구분합니다.
34 |
35 | ## 플랫폼 패키지
36 |
37 | 컴포저를 통해서 실제 설치하는것은 아니지만 가상으로 설치하되는 패키지로 플랫폼 패키지라는 것이 있습니다. 이는 PHP 자체와 PHP 익스텐션, 그리고 일부 시스템 라이브러리들이 해당됩니다. (역주 - composer로 설치하는건 아니지만 플랫폼에 해당하는 패키지들의 제한 사항을 표시한다는 의미인거 같음)
38 |
39 |
40 | * `php`는 유저의 PHP 버전으로 제약을 `>=5.4.0`와 같이 나타낼 수 있습니다. php 64비트가 필요하다면 `php-64bit` 패키지를 require 할 수도 있습니다.
41 |
42 | * `hhvm`은 HHVM 런타임의 버전을 의미하고 (HipHop Virtual Machine)'>=2.3.3'로 제약을 나타냅니다.
43 |
44 | * `ext-`를 사용해서 필요한 PHP extensions를(코어 익스텐션을 포함해서) 표현할 수 있습니다. 버전을 표시하는것은 비일관적일 수 있기 때문에 `*`와 같이 제약을 표시하는것이 좋을 수도 있습니다. 익스텐션 패키지 이름은 예를 들면 `ext-gd`와 같습니다.
45 |
46 | * `lib-`은 PHP에 쓰이는 라이브러리의 버전 제약을 나타내며 다음과 같은 것들이 있습니다. : `curl`, `iconv`, `icu`, `libxml`,
47 | `openssl`, `pcre`, `uuid`, `xsl`.
48 |
49 | 로컬환경에서 사용할 수 있는 플랫폼 패키지들의 목록은 `composer show --platform`명령어로 확인할 수 있습니다.
50 |
51 | ## 버전 표시하기
52 |
53 | 패키지에는 버전을 지정할 필요가 있습니다. 패키지를 패키지스트에 올리려고 할때 버전관리도구(git, svn, hg)를 통해서 버전 정보를 알려줄 수 있습니다.
54 | 이 경우에 버전을 특별히 지정할 필요는 없고, 또한 그렇게 하는 것을 추천합니다. 버전관리도구를 통해서 어떻게 버전번호를 확인 할지는 [tags](#tags) 와 [branches](#branches)을 참고하십시오.
55 |
56 | 만약 패키지들을 직접 만들고 반드시 버전정보를 나타내야 한다면 `version` 필드를 추가하면 됩니다.
57 |
58 | {% highlight json %}
59 | {
60 | "version": "1.0.0"
61 | }
62 | {% endhighlight %}
63 |
64 | > **주의:** 버전의 표시는 반드시 태그 이름과 맞아야 하므로 가급적 명시적으로 버전 필드를 지정하는 것은 피하시길 바랍니다.
65 |
66 | ### Tags - 태그 {#tags}
67 |
68 | 버전처럼 보여지는 태그들 만다 해당 태그에 맞는 패키지의 버전이 생성되어 집니다. 이는 `-patch`, `-alpha`, `-beta`,`-RC`같은 옵션형 접미사를 가진 'X.Y.Z' 또는 'vX.Y.Z'와 같은 형태가 됩니다. 접미사에 숫자가 쓰일 수도 있습니다.
69 |
70 | 사용할 수 있는 태그 이름들에 대한 몇가지 예시는 다음과 같습니다.
71 |
72 | - 1.0.0
73 | - v1.0.0
74 | - 1.10.5-RC1
75 | - v4.4.4-beta2
76 | - v2.0.0-alpha
77 | - v2.0.4-p1
78 |
79 |
80 | > **주의:** 태그의 버전에 `v` 접두어가 붙어 있더라도 [version constraint](/Composer-korean-docs/doc/01-basic-usage.md#package-versions) `require`를 지정할 때에는 접두어없이 지정합니다.(예를 들면 tag `v1.0.0` 는 버전 `1.0.0`을 의미합니다)
81 |
82 | ### Branches - 브랜치 {#branches}
83 |
84 | 개별 브랜치마다 패키지 개발버전이 생성됩어집니다. 만약 브랜치의 이름이 버전처럼 보이게 되어 있다면 `{branchname}-dev`와같이 됩니다.
85 | 예를들어 브랜치 `2.0`은 `2.0.x-dev`(`.x`는 브랜치를 식별하려는 기술적 이유로 부가되었습니다. 브랜치 `2.0.x`가 `2.0.x-dev`로 될 수 있습니다.) 만약 브랜치가 버전처럼 보이는 형태가 아니라면 `dev-{branchname}`형태일 것이고 `master`는 `dev-master`버전 형태가 됩니다.
86 |
87 | 버전 브랜치 이름에 대한 예제는 다음과 같습니다.
88 |
89 | - 1.x
90 | - 1.0 (equals 1.0.x)
91 | - 1.1.x
92 |
93 | > **주의:** 개발 버전을 설치할 때에는 패키지를 자동으로 `source`에서 내려받습니다.
94 | > 더 자세한 사항은 [`설치`](/Composer-korean-docs/doc/03-cli.md#install) 명령어에 대해서 참고하십시오.
95 |
96 | ### Aliases - 앨리어스
97 |
98 | 브랜치 이름을 버전으로하는 별칭을 지정 할 수 있습니다. 예를 들면 `1.0.x-dev`를 필요로 하는 모든 패키지들에서 사용하기 위해서 `dev-master` 에서 `1.0.x-dev`로 별칭을 지정(alias)할 수 있습니다. 별칭-Aliases에 관한 추가정보는 [Aliases](/Composer-korean-docs/doc/articles/aliases.md)부분을 참고하십시오.
99 |
100 | ## Lock file
101 |
102 | 함께 협업하는 팀 모두가 항상 같은 의존성 버전으로 테스팅 할 수 있게 해주기 위해 필요한 경우에 `composer.lock` 파일을 포함하여 커밋할 수 있습니다. lock 파일은 다른 프로젝트에는 형상을 주지 않고 해당 프로젝트에만 적용됩니다.
103 |
104 | 만약 lock file을 커밋하기를 원치 않고 현재 git을 사용하고 있다면 `.gitignore`에 lock 파일을 추가하면 됩니다.
105 |
106 | ## 버전관리도구로 퍼블리싱하기
107 |
108 | 이미 VCS 저장소를 보유하고 있고(버전관리 시스템 예를들어 git) `composer.json` 파일을 보유하고 있다면 해당 라이브러리는 컴포저로 설치가 가능해집니다.
109 |
110 | 다음 예에서 github의 `github.com/username/hello-world`에 라이브러리 `acme/hello-world`를 퍼블리싱 하는 것을 보여드리겠습니다.
111 |
112 | 먼저 `acme/hello-world` 패키지를 인스톨하는것을 테스트 하기 위해서 로컬 환경에 새로운 프로젝트를 만듭니다. 이 패키지를 `acme/blog`라고 합시다. 이 블로그는 `monolog/monolog`에 의존성을 가지고 있는 `acme/hello-world`에 대한 의존성을 가지고 있습니다. 이 디렉토리에 다음과 같이 `composer.json`을 생성합니다.
113 |
114 | {% highlight json %}
115 | {
116 | "name": "acme/blog",
117 | "require": {
118 | "acme/hello-world": "dev-master"
119 | }
120 | }
121 | {% endhighlight %}
122 |
123 | 이 블로그 라이브러리를 퍼블리싱-배포하지 않는다면 name 필드가 꼭 필요하지는 않지만 앞서 이야기한 `composer.json`에 대한 설명을 보여주기 위해서 추가해놓았습니다.
124 |
125 | 이제 이 블로그 라이브러리가 어디에서 `hello-world`에 대한 의존성 패키지를 찾을 수 있는지 알려주어야 합니다. 다음처럼 repository에 대한 스펙을 추가하여 어디에서 찾을 수 있는지 알려줄 수 있습니다.
126 |
127 | `composer.json`:
128 |
129 | {% highlight json %}
130 | {
131 | "name": "acme/blog",
132 | "repositories": [
133 | {
134 | "type": "vcs",
135 | "url": "https://github.com/username/hello-world"
136 | }
137 | ],
138 | "require": {
139 | "acme/hello-world": "dev-master"
140 | }
141 | }
142 | {% endhighlight %}
143 |
144 | 레파지토리-저장소가 어떻게 작동하고 사용 할 수 있는 자세한 사항들에 대해서는 [Repositories](/Composer-korean-docs/doc/05-repositories.md)챕터를 참고하십시오.
145 |
146 | 자 이제 다 됬습니다. 이제 컴포저의 `install` 명령어를 통해서 의존 패키지들을 다운로드 할 수 있습니다.
147 |
148 | **요약:** 어떠한 git/svn/hg 저장소라도 `composer.json`파일을 포함하고 있다면 프로젝트에서 필요로 하는 패키지들을 저장소 스펙에 맞게 추가하는 것만으로도 의존성 관리를 할 수 있습니다.
149 |
150 | ## 패키지스트(packagist)로 퍼블리싱하기
151 |
152 | 이제 패키지들을 퍼블리싱 할 수 있게 되었습니다. 하지만 매번 VCS 저장소를 추가하는 것은 매우 어려운 일입니다. 그리고 실제로 매번 이렇게 할 필요는 없습니다.
153 |
154 | 생각해 보면 `monolog/monolog`는 패키지 저장소를 따로 지정해주지 않았지만 정상적으로 작동했습니다. 어떻게 이러한일이 가능했을 까요? 정답은 바로 패키지스트(packagist)입니다.
155 |
156 | [Packagist](https://packagist.org/)는 컴포저용 주요 패키지 저장소를 말하며 컴포저에 기본으로 설정돼 있습니다. 패키지스트에 퍼블리싱된 것들은 자동으로 컴포저로 사용할 수 있습니다. 따라서 추가적으로 저장소에 대한 정보없이도 monolog [패키지스트에서 보기](https://packagist.org/packages/monolog/monolog)를 사용할 수 있는 것입니다.
157 |
158 | If we wanted to share `hello-world` with the world, we would publish it on
159 | packagist as well. Doing so is really easy.
160 |
161 | 만약 우리가 `hello-world`를 공유하기 원한다면 이 또한 패키지스트에 올리면 됩니다(퍼블리싱). 이 또한 아주 쉽게 가능합니다.
162 |
163 | 간단하게 말해서 "Submit Package" 버튼을 클릭하고 가입을 한 뒤에 보유한 버전관리도구 저장소의 URL을 입력하면 패키지스트가 알아서 크롤링을 하게 됩니다. 이것이 전부이며 이제 패키지스트를 통해서 퍼블리싱한 패키지를 누구나 사용할 수 있게 됩니다.
164 |
165 | ← [기본 사용법](/Composer-korean-docs/doc/01-basic-usage.md) | [커맨드라인 인터페이스 / 명령어](/Composer-korean-docs/doc/03-cli.md) →
--------------------------------------------------------------------------------
/doc/03-cli.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "커맨드라인 인터페이스 / 명령어"
4 | permalink: /doc/03-cli.md/
5 | ---
6 |
7 | # 커맨드라인 인터페이스 / 명령어
8 |
9 | 이미 여려분은 이 앞에서 커맨드라인 인터페이스를 사용하는 방법을 익혔습니다. 이 챕터에서는 모든 명령어들에 대해서 정리해 보겠습니다.
10 |
11 | 커맨드라인에 대한 도움말을 확인하고자 한다면, `composer` 또는 `composer list`를 입력하여 전체 명령어 목록을 확인한 다음에, 각 명령어 뒤에 `--help`를 붙이면 추가적인 정보를 확인 수 있습니다.
12 |
13 | ## 글로벌 옵션
14 |
15 | 다음의 옵션들은 모든 명령어에서 사용할 수 있습니다:
16 |
17 | * **--verbose (-v):** 출력 메시지를 더 상세하게 나타내줍니다.
18 | * **--help (-h):** 도움말 정보를 표현합니다.
19 | * **--quiet (-q):** 어떠한 메시지도 출력하지 않습니다.
20 | * **--no-interaction (-n):** 어떠한 대화형 질문도 하지 않습니다.
21 | * **--working-dir (-d):** 만약 옵션이 지정되면, 지정된 디렉토리를 작업 디렉토리로 사용합니다.
22 | * **--profile:** 수행 시간과 메모리 사용 정보를 표현합니다.
23 | * **--ansi:** 강제로 ANSI로 출력합니다.
24 | * **--no-ansi:** ANSI 출력을 할 수 없게 합니다.
25 | * **--version (-V):** 이 애플리케이션의 버전을 표현합니다.
26 |
27 | ## 프로세스 종료 코드
28 |
29 | * **0:** OK
30 | * **1:** 포괄적인/알려지지 않은 에러 코드
31 | * **2:** 의존성 해결 에러 코드
32 |
33 | (역자주 - 프로세스 종료코드는 실제 커맨드라인에서 명령어를 입력했을 때는 잘 알 수 없지만 composer 를 연동해서 작업을 수행해야하는 CI(continuous integration) 나 기타 시스템 스크립트 수행이 필요한 경우에 정상동작여부를 확인할 수 있게 제공되는 부분입니다. 만약 리눅스나 Mac 의 터미널이라면 composer 의 아무 명령어를 입력하고 $?를 입력하면 정상동작한 경우에 0, 에러가 난경우에는 1, 의존성 패키지 관련 에러는 2가 출력되는것을 확인할 수 있습니다.)
34 |
35 |
36 | ## init - 초기화
37 |
38 | [라이브러리](/Composer-korean-docs/doc/02-libraries.md) 챕터에서 `composer.json` 을 수동으로 만드는 방법을 살펴보았습니다. `init` 명령어는 이 작업을 조금 더 쉽게할 수 있게 해줍니다.
39 |
40 | 명령어를 실행하면 몇가지 질문들에 대한 답을 통해서 필드들에 대한 기본값을 채우도록 할 것입니다.
41 |
42 | {% highlight sh %}
43 | php composer.phar init
44 | {% endhighlight %}
45 |
46 | ### 초기화 옵션
47 |
48 | * **--name:** 패키지 이름.
49 | * **--description:** 패키지 설명.
50 | * **--author:** 패키지 작성자의 이름
51 | * **--homepage:** 패키지의 홈페이지.
52 | * **--require:** 버전 제약하에 필요한 패키지들. `foo/bar:1.0.0`의 형태여야 합니다.
53 | * **--require-dev:** 개발시 필요한 것들, **--require**를 보세요.
54 | * **--stability (-s):** `minimum-stability` 필드 값.
55 |
56 | ## 설치 {#install}
57 |
58 | `install` 명령어는 현재 디렉토리에 있는 `composer.json` 파일을 읽고, 의존성을 해석하여, `vendor`에 패키지들을 설치합니다.
59 |
60 | {% highlight sh %}
61 | php composer.phar install
62 | {% endhighlight %}
63 |
64 | 만약 현재 디렉토리에 `composer.lock` 파일이 있으면, 의존성을 해석하는 대신 `composer.lock`에 있는 것과 일치하는 버전을 사용할 것입니다. 이것은 라이브러리를 사용하는 사람들이 동일한 의존성 버전을 갖도록 보장해줍니다.
65 |
66 | 만약 `composer.lock` 파일이 없다면, 컴포저는 의존성을 해석한 후 새롭게 파일을 만들 것입니다.
67 |
68 | ### 설치 옵션
69 |
70 | * **--prefer-source:** 패키지를 다운로드 하는 데에는 `source`와 `dist` 두가지 방법이 존재합니다. 안정화 버전에서는 `dist`가 기본값으로 쓰일것입니다. `source`는 버전 관리 저장소를 의미합니다. 만약 `--prefer-source`옵션을 사용하면, 컴포저는 `source`로 부터 설치를 하는데, 이러한 경우는 프로젝트에 버그를 수정하려 할때와 의존 패키지의 로컬 git에 복제하는데에 유용합니다.
71 | * **--prefer-dist:** `--prefer-source`와 반대로, 가능하다면 컴포저는 `dist`로부터 설치를 합니다. 이 방법은 일반적으로 벤더를 업데이트 하지 않는 케이스와 빌드 서버로 부터 설치를 진행하는 형태로 설치 속도를 빠르게 해줄 수 있습니다. 또한 적절하게 셋업되지 않은 경우에 발생할 수 있는 git과 관련된 문제를 피하는 방법이기도 합니다.
72 | * **--ignore-platform-reqs:** `php`, `hhvm`, `lib-*` 와 `ext-*`등의 요구사항을 무시하고 로컬 머신이 이 조건을 만족하지 못한다고 하더라도 설치를 강행합니다.
73 | * **--dry-run:** 만약 실제로 패키지들을 설치 하지 않고 빠르게 설치과정만을 살펴보길 원한다면, `--dry-run`을 사용할 수 있습니다. 이것은 설치를 시뮬레이션 해보고 어떤일이 발생하는지 보여줍니다.
74 | * **--dev:** `require-dev`에 있는 패키지들을 설치합니다 (기본설정된 행동입니다).
75 | * **--no-dev:** `require-dev`에 있는 패키지들을 설치하지 않고 스킵합니다.
76 | * **--no-autoloader:** 오토로더를 생성하지 않고 넘어갑니다.
77 | * **--no-scripts:** `composer.json`에 정의된 스크립트를 실행하지 않고 넘어갑니다.
78 | * **--no-plugins:** 플러그인들을 사용하지 않습니다.
79 | * **--no-progress:** 몇몇 터미널이나 백스페이스문자(\\)가 처리되지 않는 스크립트들에서 화면이 지저분 해질 수 있는 진행 화면 표시기능을 제거합니다.
80 | * **--optimize-autoloader (-o):** PSR-0/4 오토로딩을 클래스맵으로 전환시켜서 오토로더를 더 빠르게 합니다. 특히 프로덕션에 추천되지만, 시간이 조금 걸릴 수 있어서 현재는 기본설정에서는 빠져있습니다.
81 |
82 | ## 업데이트
83 |
84 | 의존성을 설정한 패키지들의 최신버전을 다운받고, `composer.lock` 파일을 업데이트 하기 위해서는, `update` 명령어를 사용합니다.
85 |
86 | {% highlight sh %}
87 | php composer.phar update
88 | {% endhighlight %}
89 |
90 | 업데이트 명령어는 프로젝트의 모든 의존관계럴 설정한 패키지들을 확인하고`composer.lock`에 정확한 버전을 기입해줍니다.
91 |
92 | 만약 전체 패키지가 아닌 일부 패키지만 업데이트하길 원한다면, 다음과 같이 할 수 있습니다.
93 |
94 | {% highlight sh %}
95 | php composer.phar update vendor/package vendor/package2
96 | {% endhighlight %}
97 |
98 | 와일드카드를 사용해서 패키지들을 한 번에 업데이트 할 수도 있습니다.
99 |
100 | {% highlight sh %}
101 | php composer.phar update vendor/*
102 | {% endhighlight %}
103 |
104 | ### 업데이트 옵션
105 |
106 | * **--prefer-source:** 가능한 경우 `source`로 부터 패키지를 설치합니다.
107 | * **--prefer-dist:** 가능한 경우 `dist`로 부터 패키지를 설치합니다.
108 | * **--ignore-platform-reqs:** `php`, `hhvm`, `lib-*` 와 `ext-*` 요구사항을 무시하고 로컬 머신이 이 조건을 만족하지 못한다고 하더라도 설치를 강행합니다.
109 | * **--dry-run:** 실제로는 명령을 수행하진 않고 시뮬레이션 합니다.
110 | * **--dev:** `require-dev`에 있는 패키지들을 설치합니다 (기본 설정입니다).
111 | * **--no-dev:** `require-dev`에 있는 패키지들은 설치하지 않고 넘어갑니다.
112 | * **--no-autoloader:** 오토로더를 생성하지 않고 넘어갑니다.
113 | * **--no-scripts:** `composer.json`에 정의된 스크립트를 실행하지 않고 넘어갑니다.
114 | * **--no-plugins:** 플러그인을 사용하지 않습니다.
115 | * **--no-progress:** 몇몇 터미널이나 백스페이스문자(\\)가 처리되지 않는 스크립트들에서 화면이 지저분 해질 수 있는 진행 화면 표시기능을 제거합니다.
116 | * **--optimize-autoloader (-o):** PSR-0/4 오토로딩을 클래스맵으로 전환시켜서 오토로더를 더 빠르게 합니다. 특히 프로덕션에 추천되지만, 시간이 조금 걸릴 수 있어서 현재는 기본설정에서는 빠져있습니다.
117 | * **--lock:** lock 파일이 오래되었다는 경고를 나오지 않게 하기 위해 lock 파일의 해시만 업데이트 합니다.
118 | * **--with-dependencies** 화이트리스트에 화이트리스트 패키지의 모든 의존성을 추가합니다.
119 | * **--prefer-stable:** 안정 버전(Stable version)의 의존성을 우선합니다.
120 | * **--prefer-lowest:** 낮은 버전의 의존성을 우선합니다. 요구사항의 최소 버전을 테스트 하는데 유용하며, 일반적으로 `--prefer-stable`과 함께 쓰입니다.
121 |
122 | ## require
123 |
124 | `require` 명령어는 현재 디렉토리에 있는 `composer.json` 파일에 새로운 패키지들을 추가하는 명령어입니다.
125 |
126 | `composer.json` 파일이 존재하지 않는 경우에는 파일을 직접 생성합니다.
127 |
128 | {% highlight sh %}
129 | php composer.phar require
130 | {% endhighlight %}
131 |
132 | 필요로 하는 패키지를 추가하거나 변경한 이후에는 자동으로 설치하거나 업데이트가 수행됩니다.
133 |
134 | 만약 요구사항이 호환이 되지 않게 하길 원한다면, 다음과 같은 방법으로 무시할 수 있습니다.
135 | If you do not want to choose requirements interactively, you can just pass them to the command.
136 |
137 | {% highlight sh %}
138 | php composer.phar require vendor/package:2.* vendor/package2:dev-master
139 | {% endhighlight %}
140 |
141 | ### require 옵션
142 |
143 | * **--prefer-source:** 가능한 경우 `source`로 부터 패키지를 설치합니다.
144 | * **--prefer-dist:** 가능한 경우 `dist`로 부터 패키지를 설치합니다.
145 | * **--ignore-platform-reqs:** `php`, `hhvm`, `lib-*` 와 `ext-*` 요구사항을 무시하고 로컬 머신이 이 조건을 만족하지 못한다고 하더라도 설치를 강행합니다.
146 | * **--dev:** `require-dev`에 패키지들을 추가합니다.
147 | * **--no-update:** 의존성 패키지들을 자동으로 업데이트 하지 않습니다.
148 | * **--no-progress:** 몇몇 터미널이나 백스페이스문자(\\)가 처리되지 않는 스크립트들에서 화면이 지저분 해질 수 있는 진행 화면 표시기능을 제거합니다.
149 | * **--update-no-dev** "--no-dev" 옵션을 추가하여 의존성 업데이트를 진행합니다.(`require-dev`에 있는 패키지들은 설치하지 않고 넘어갑니다.)
150 | * **--update-with-dependencies** 기존의 의존성이 있는 항목 이외에도 새롭게 필요로하는 패키지를 함께 업데이트 합니다.
151 |
152 | ## remove - 삭제
153 | `remove` 명령어는 현재 디렉토리에 있는 `composer.json` 파일 안에 적혀있는 패키지를 제거하는 명령어입니다.
154 |
155 | {% highlight sh %}
156 | php composer.phar remove vendor/package vendor/package2
157 | {% endhighlight %}
158 | 패키지들을 제거한 후에, 변경된 패키지 요구사항들(require)은 자동으로 삭제됩니다.
159 |
160 | ### 삭제 옵션
161 | * **--ignore-platform-reqs:** `php`, `hhvm`, `lib-*` 와 `ext-*` 요구사항을 무시하고 로컬 머신이 이 조건을 만족하지 못한다고 하더라도 설치를 강행합니다.
162 | * **--dev:** `require-dev`에 있는 패키지들을 제거합니다.
163 | * **--no-update:** 의존성 패키지들을 자동으로 업데이트 하지 않습니다.
164 | * **--no-progress:** 몇몇 터미널이나 백스페이스문자(\\)가 처리되지 않는 스크립트들에서 화면이 지저분 해질 수 있는 진행 화면 표시기능을 제거합니다.
165 | * **--update-no-dev** "--no-dev" 옵션을 추가하여 의존성 업데이트를 진행합니다.(`require-dev`에 있는 패키지들은 설치하지 않고 넘어갑니다.)
166 | * **--update-with-dependencies** 기존의 의존성이 있는 항목 이외에도 새롭게 필요로하는 패키지를 함께 업데이트 합니다.
167 |
168 | ## global - 글로벌
169 |
170 | global 명령어는 [컴포저 홈 디렉토리](#composer-home)에 있는 패키지들도 `install`, `require`, `update`와 같은 다른 명령어를 쓸 수 있도록 해줍니다.
171 |
172 | 이 명령어는 CLI 유틸리티를 전역(globally)설치할 때 사용할 수 있습니다. 필요한 경우에 `$COMPOSER_HOME/vendor/bin`을 로컬 환경의 `$PATH` 환경 변수로 추가하면 유용하게 컴포저 홈 디렉토리에 접근할 수 있습니다. 여기 예제가 있습니다:
173 |
174 | {% highlight sh %}
175 | php composer.phar global require fabpot/php-cs-fixer:dev-master
176 | {% endhighlight %}
177 |
178 | 이제 `php-cs-fixer` 바이너리는 어디에서든지 사용이 가능해졌습니다.(PATH에 적용을 했다면). 만약 나중에 바이너리를 업데이트 하고 싶다면, 그냥 global update를 사용하면 됩니다:
179 |
180 | {% highlight sh %}
181 | php composer.phar global update
182 | {% endhighlight %}
183 |
184 | (역자주 - 컴포저를 홈 디렉토리에 추가하는 경우는 주로 phpunit, phpcs, laravel-homestead 와 같이 패키지에서 실행가능한 바이너리를 제공하는 경우에 많이 사용된다고 할 수 있습니다. phpunit 의 경우에 모든 개별 프로젝트 vendor 에 추가할 필요없이 글로벌로 설치해 놓으면 어디서든 접근이 가능해지기 때문입니다.)
185 |
186 | ## search - 검색
187 |
188 | `search` 명령어는 현재 프로젝트의 저장소를 검색할 수 있도록 만들어 줍니다. 기본적으로 저장소는 패키지스트로 설정되어 있습니다. 간단하게 search 명령어를 통해서 당신이 찾고 싶은 단어를 전달하면 됩니다.
189 |
190 | {% highlight sh %}
191 | php composer.phar search monolog
192 | {% endhighlight %}
193 |
194 | 또한 여러개의 단어를 명령어 뒤에 붙여서 사용하면 하나 이상의 단어에 대한 패키지들을 찾을 수 있습니다.
195 |
196 | ### 검색 옵션
197 |
198 | * **--only-name (-N):** 이름을 통해서만 검색합니다.
199 |
200 | ## show - 보기
201 |
202 | 사용가능한 모든 패키지의 목록을 확인하기 위해, `show` 명령어를 사용하면 됩니다.
203 |
204 | {% highlight sh %}
205 | php composer.phar show
206 | {% endhighlight %}
207 |
208 | (역자주 - 위의 명령어는 패키지스트를 통해서 설치 가능한 모든 패키지들의 목록을 확인하는 명령어로 수행 시간이 30초 이상, 오래걸릴 수 있습니다.)
209 |
210 | 만약에 패키지의 보다 상세한 정보를 보고 싶다면, 패키지 이름을 뒤에 입력하면 됩니다.
211 |
212 |
213 | {% highlight sh %}
214 | php composer.phar show monolog/monolog
215 |
216 | name : monolog/monolog
217 | versions : master-dev, 1.0.2, 1.0.1, 1.0.0, 1.0.0-RC1
218 | type : library
219 | names : monolog/monolog
220 | source : [git] http://github.com/Seldaek/monolog.git 3d4e60d0cbc4b888fe5ad223d77964428b1978da
221 | dist : [zip] http://github.com/Seldaek/monolog/zipball/3d4e60d0cbc4b888fe5ad223d77964428b1978da 3d4e60d0cbc4b888fe5ad223d77964428b1978da
222 | license : MIT
223 |
224 | autoload
225 | psr-0
226 | Monolog : src/
227 |
228 | requires
229 | php >=5.3.0
230 | {% endhighlight %}
231 |
232 | 패키지 이름 뒤에 버전까지 입력하면, 입력한 버전에 대한 상세정보를 볼 수 있습니다.
233 |
234 |
235 | {% highlight sh %}
236 | php composer.phar show monolog/monolog 1.0.2
237 | {% endhighlight %}
238 |
239 | ### 보기 옵션(show Options)
240 |
241 | * **--installed (-i):** 현재 프로젝트에 이미 설치된 패키지들의 리스트를 보여줍니다.
242 | * **--platform (-p):** 플랫폼 패키지만 리스트로 보여줍니다.(php or hhvm or extensions).
243 | * **--self (-s):** 현재 프로젝트의 요약 정보를 목록으로 보여줍니다.
244 |
245 | ## browse / home
246 |
247 | `browse`(별칭 `home`)는 브라우저로 패키지 저장소 URL 또는 홈페이지를 엽니다.
248 |
249 | ### 옵션
250 |
251 | * **--homepage (-H):** 저장소 URL 대신 홈페이지를 오픈하게 합니다.
252 |
253 | ## depends
254 |
255 | `depends` 명령은 `composer.json`에 열거된 패키지 중에서 특정 패키지에 종속적인 패키지들을 보여줍니다. `require`, `require-dev` 옵션을 사용해서 열거할 패키지 종류를 지정할 수 있습니다. 지정하지 않으면 둘 다 사용됩니다.
256 |
257 |
258 | {% highlight sh %}
259 | php composer.phar depends --link-type=require monolog/monolog
260 |
261 | nrk/monolog-fluent
262 | poc/poc
263 | propel/propel
264 | symfony/monolog-bridge
265 | symfony/symfony
266 | {% endhighlight %}
267 |
268 | ### depends 옵션
269 |
270 | * **--link-type:** 열거할 링크 타입. 여러번 지정할 수 있습니다.
271 | (역자주 link-type : require, require-dev)
272 |
273 | ## validate - 유효성 검사
274 |
275 | `comoser.json`을 커밋하거나 릴리즈를 하기 위해서 버전을 태깅하기 전에 반드시 `validate` 명령을 실행하길 바랍니다. 이 명령어는 `composer.json` 파일이 유효한지 검사해줍니다.
276 |
277 | {% highlight sh %}
278 | php composer.phar validate
279 | {% endhighlight %}
280 |
281 | ### validate 옵션
282 |
283 | * **--no-check-all:** 유효성 검사를 철저하게 할지 안할지 여부 지정
284 |
285 | ## status
286 |
287 | 패키지를 `source`에서 설치를 하고, 이 소스를 종종 수정할 필요가 있다면, `status` 명령을 사용해서 로컬에 저장된 소스에 변경사항이 있는지 확인할 수 있습니다.
288 |
289 | {% highlight sh %}
290 | php composer.phar status
291 | {% endhighlight %}
292 |
293 | `--verbose` 옵션과 같이 사용하면 변경된 내용에 대해 더 자세한 정보를 알 수 있습니다.
294 |
295 | {% highlight sh %}
296 | php composer.phar status -v
297 |
298 | You have changes in the following dependencies:
299 | vendor/seld/jsonlint:
300 | M README.mdown
301 | {% endhighlight %}
302 |
303 | (역자주 - 의존성 패키지들을 source 에서 받으면 git 저장소에서 복제하는 형태로 파일을 가져오고 dist 에서 받으면 zip 파일과 같이(존재한다면) 압축되어 있는 파일을 받는 형태로 설치 또는 업데이트가 진행됩니다. 따라서 일반적으로 dist 를 통해서 설치 또는 업데이트를 하는 것이 속도가 더 빠릅니다. status 명령어는 source 에서 설치한 경우에 해당 패키지들을 임의로 수정한 경우, 원래의 내용과 내가 임의로 수정한 vendor 밑에 패키지의 변경상태가 어떠한지 비교해서 보여줍니다. )
304 |
305 | ## self-update (컴포저 update)
306 |
307 | composer 자체를 최신의 버전으로 갱신하려면, `self-update` 명령을 실행하십시요. 이 명령은 `composer.phar`을 최신의 버전으로 교체합니다.
308 |
309 | (역자주 - 일반적으로 composer는 30일 동안 업데이트 하지 않으면 경고가 나타납니다. )
310 |
311 | {% highlight sh %}
312 | php composer.phar self-update
313 | {% endhighlight %}
314 |
315 | 특정 버전으로 갱신하려면, 버전정보를 뒤에 지정하면 됩니다:
316 |
317 | {% highlight sh %}
318 | php composer.phar self-update 1.0.0-alpha7
319 | {% endhighlight %}
320 |
321 | 만약 composer를 시스템에 글로벌하게 설치했다면 ([글로벌 설치](/Composer-korean-docs/doc/00-intro.md#globally) 참고),
322 | `root` 권한으로 이 명령을 실행해야 합니다.
323 |
324 | {% highlight sh %}
325 | sudo composer self-update
326 | {% endhighlight %}
327 |
328 | ### self-update 옵션
329 |
330 | * **--rollback (-r):** 설치된 가장 최신의 버전으로 롤백합니다.
331 | * **--clean-backups:** 갱신하면서 이전 백업본을 삭제합니다. 이 옵션을 사용하면 현재 갱신된 버전이 유일한 백업본이 됩니다.
332 |
333 | (역자주 - composer self-update 를 수행하면 컴포저 홈 디렉토리에 이전 버전의 컴포저 파일이 저장되어 지고, 롤백을 통해서 다시 복구하거나, 저장된 이전 버전의 컴포저 파일을 clean-backups 를 통해서 삭제할 수 있습니다.)
334 |
335 | ## config - 설정
336 |
337 | `config` 명령어는 로컬 composer.json 파일 또는 글로벌 config.json 파일에 설정된 몇가지의 기본적인 컴포져 설정들을 편집할 수 있게 해줍니다.
338 |
339 | {% highlight sh %}
340 | php composer.phar config --list
341 | {% endhighlight %}
342 |
343 | ### 사용법
344 |
345 | `config [options] [setting-key] [setting-value1] ... [setting-valueN]`
346 |
347 | `setting-key`는 설정 옵션 이름이며 `setting-value1`은 설정 값입니다.
348 | (`github-protocols`과 같은) 값의 배열을 취할 수 있는 설정들에는 하나 이상의
349 | setting-value 인자들이 허용됩니다.
350 |
351 | 사용 가능한 설정 옵션에 대해서는 [설정 스키마 섹션](/Composer-korean-docs/doc/04-schema.md#config)을
352 | 참조하십시오.
353 |
354 | ### 옵션
355 |
356 | * **--global (-g):** 기본적으로 `$COMPOSER_HOME/config.json`에 위치한 글로벌 설정 파일을 조작합니다. 이 옵션이 없으면, 이 명령은 로컬 composer.json 파일 또는 `--file`에서 지정한 파일에 영향을 줍니다.
357 | * **--editor (-e):** `EDITOR` 환경 변수에 정의된 텍스트 편집기를 사용하여 로컬 composer.json 파일을 엽니다. `--global` 옵션을 지정하면, 글로벌 설정 파일을 엽니다.
358 | * **--unset:** `setting-key`로 명명된 설정 요소를 제거합니다.
359 | * **--list (-l):** 현재 설정 변수들의 목록을 보여줍니다. `--global` 옵션을
360 | 지정하면, 글로벌 설정만을 보여줍니다.
361 | * **--file="..." (-f):** composer.json 대신에 특정 파일을 조작합니다. `--global` 옵션과 함께 사용할 수 없습니다.
362 | * **--absolute:** *-dir 설정 값을 가져올 때 상대 경로 대신 절대 경로를 반환합니다.
363 |
364 | ### 저장소 수정하기
365 |
366 | 설정 섹션을 변경할뿐만 아니라, `config` 명령은 다음 방법을 사용하여 저장소
367 | 섹션을 변경하는 것 또한 지원합니다:
368 |
369 | {% highlight sh %}
370 | php composer.phar config repositories.foo vcs http://github.com/foo/bar
371 | {% endhighlight %}
372 |
373 | ## create-project (프로젝트 생성)
374 |
375 | 컴포저를 이용하면 기존 패키지에서 새로운 프로젝트를 만들 수 있습니다. 이는 git
376 | clone/svn checkout 한 후 그 밴더의 컴포저를 설치(install)한 것과 같습니다.
377 |
378 | 이것에 관한 몇 가지 응용이 있습니다:
379 |
380 | 1. 애플리케이션 패키지들을 배포 할 수 있습니다.
381 | 2. 어떤 패키지를 체크아웃 하고, 패치들에 개발을 시작 할 수 있습니다.
382 | 3. 여러 개발자들이 함께하는 프로젝트는 개발을 위한 초기 애플리케이션을
383 | 부트스트랩 하기 위해 이 기능을 사용할 수 있습니다.
384 |
385 | "create-project" 명령어를 실행하면 컴포져를 이용해 새 프로젝트를 만듭니다.
386 | 패키지명을 전달하고, 디렉토리에 프로젝트를 만듭니다. 또한 세 번째 인수로 버전을
387 | 지정 할 수 있습니다. 그렇지 않은 경우 최신 버전이 사용됩니다.
388 |
389 | 해당 디렉토리가 존재하지 않는 경우 설치 중에 새롭게 생성됩니다.
390 |
391 | {% highlight sh %}
392 | php composer.phar create-project doctrine/orm path 2.2.*
393 | {% endhighlight %}
394 |
395 | 프로젝트를 부트스트랩하기 위해 `composer.json` 파일이 위치한 디렉토리 내에서
396 | 별도의 파라미터 없이 명령을 실행할 수도 있습니다.
397 |
398 | 기본값에 따라 이 명령은 packagist.org에서 패키지를 확인합니다.
399 |
400 | ### 옵션
401 |
402 | * **--repository-url:** 패키지 검색을 위한 사용자 저장소를 지정하며, 이는
403 | packagist 대신에 사용됩니다. `composer` 저장소를 가리키는 HTTP URL 또는 로컬
404 | `packages.json` 파일 경로 중 하나가 될 수 있습니다.
405 | * **--stability (-s):** 패키지의 최소 안전성. 기본값은 `stable`.
406 | * **--prefer-source:** 가능한 `source`로부터 패키지를 설치합니다.
407 | * **--prefer-dist:** 가능한 `dist`로부터 패키지를 설치합니다.
408 | * **--dev:** `require-dev` 내 열거 된 패키지를 설치합니다.
409 | * **--no-install:** 밴더의 설치를 금지합니다.
410 | * **--no-plugins:** 플러그인을 금지합니다.
411 | * **--no-scripts:** 루트 패키지에 정의된 스크립트들의 실행을 금지합니다.
412 | * **--no-progress:** 백스페이스 캐릭터를 다루지 않는 일부 터미널이나 스크립트를
413 | 어지럽히는 진행 표시를 제거합니다.
414 | * **--keep-vcs:** 생성된 프로젝에 관한 VCS 메타데이터의 삭제를 건너뜁니다.
415 | 비대화식 모드에서 명령을 실행하는 경우에 유용합니다.
416 | * **--ignore-platform-reqs:** `php`, `hhvm`, `lib-*`, `ext-*` 요구사항들을
417 | 무시하고, 로컬 머신이 이들을 충족하지 않은 경우에도 강제로 설치합니다.
418 |
419 | ## dump-autoload (오토로드 덤프)
420 |
421 | 클래스맵 패키지 안의 새로운 클래스들 때문에 오토로더를 업데이트 할 필요가 있는
422 | 경우, install 또는 update를 통하지 않고 "dump-autoload" 사용 할 수 있습니다.
423 |
424 | 또한, 성능상의 이유로 classmap에 PSR-0/4 패키지를 변환한 최적화 된 오토로더를
425 | 덤프 할 수 있습니다. 많은 클래스를 가진 커다란 애플리케이션에서 오토로더는 매
426 | 요청 시간의 상당 부분을 차지 할 수 있습니다. 모든 클래스에 대해 클래스맵을
427 | 사용하는 것은 개발 중에 편리함이 적습니다. 하지만 이 옵션을 사용하면 편리함을
428 | 위한 PSR-0/4와 성능을 위한 클래스맵을 여전히 사용 할 수 있습니다.
429 |
430 | ### 옵션
431 |
432 | * **--optimize (-o):** 빠른 오토로더를 얻기 위해 클래스맵으로 PSR-0/4
433 | 오토로딩을 변환합니다. 이것을 특히 production을 위해 권장됩니다. 그러나
434 | 실행하는데 시간이 조금 걸릴 수 있기 때문에 현재 기본값으로 수행하진 않습니다.
435 | * **--no-dev:** autoload-dev 규칙을 금지합니다.
436 |
437 | ## clear-cache
438 |
439 | 컴포져 캐쉬 디렉토리들 안의 모든 컨텐츠를 삭제합니다.
440 |
441 | ## licenses
442 |
443 | 설치 된 모든 패키지의 이름, 버전, 라이센스를 보여줍니다. 기계가 읽을 수 있는
444 | 출력을 얻기 위해서는 `--format=json`을 사용합니다.
445 |
446 | ### 옵션
447 |
448 | * **--no-dev:** 출력에 dev 의존성을 제거합니다.
449 | * **--format:** 출력 포맷: text 또는 json (기본값: "text")
450 |
451 | ## run-script
452 |
453 | 수동으로 [스크립트](/Composer-korean-docs/doc/articles/scripts.md)를 실행하기 위해 스크립트 이름과 개발
454 | 모드 해제할 경우 선택적으로 --no-dev를 주고 이 명령을 사용합니다.
455 |
456 | ## diagnose - 진단하기
457 |
458 | 만약 버그나 어떤 잘못된 부분을 찾은것 같다고 생각된다면 `diagnose`명령어를 통해서 여러 공통된 문제들에 대해서 자동으로 진단해 볼 수 있습니다.
459 |
460 |
461 | {% highlight sh %}
462 | php composer.phar diagnose
463 | {% endhighlight %}
464 |
465 | (역자주 : diagnose 를 통해서 체크하는 부분들은
466 | - composer.json 의 유효성
467 | - platform 셋팅
468 | - git 셋팅
469 | - http 접속상태
470 | - github oauth 접속 가능여부
471 | - disk 여유공간 점검
472 | - 최신 composer 버전 사용여부 입니다 )
473 |
474 | ## archive - 아카이브(압축파일)
475 |
476 | 이 명령어는 패키지의 버전별 zip/tar 압축파일을 생성하는 용도로 사용됩니다. 또는 제외되거나 무시되는 파일 없이 프로젝트 전체를 압축파일로 하는데 사용될 수도 있습니다.
477 |
478 | {% highlight sh %}
479 | php composer.phar archive vendor/package 2.0.21 --format=zip
480 | {% endhighlight %}
481 |
482 | ### 아카이브 - 옵션
483 |
484 | * **--format (-f):** 압축결과 파일의 포맷을 결정합니다: tar or zip (기본: "tar")
485 | * **--dir:** 현재 디렉토리에 압축파일 쓰기 (기본: ".")
486 |
487 | ## help - 도움말
488 |
489 | 어떠한 명령어에 대한 더 많은 정보를 알고 싶다면 `help`를 입력하면 됩니다.
490 |
491 | {% highlight sh %}
492 | php composer.phar help install
493 | {% endhighlight %}
494 |
495 | ## Environment variables - 환경변수
496 |
497 | 컴포저에는 사용자가 설정을 변경할 수 있는 환경변수들이 존재합니다.
498 | 가능하다면 환경변수는 `composer.json`의 `config` 섹션에 설정하기를 권장합니다. 이 환경변수들은 `composer.json`에 명시되어 있는 값들보다 우선하여 적용된다는 것에 주목하십시오.
499 |
500 | ### COMPOSER - 컴포저
501 |
502 | `COMPOSER`의 환경변수를 셋팅함으로써, 다른 형태의 'composer.json'을 설정이 가능합니다.
503 |
504 | 예를 들어:
505 |
506 | {% highlight sh %}
507 | COMPOSER=composer-other.json php composer.phar install
508 | {% endhighlight %}
509 | 와 같이도 설정가능합니다.
510 |
511 |
512 | ### COMPOSER_ROOT_VERSION - 컴포저 루트 버전
513 |
514 | 만약 VCS 정보로 부터 루트 패키지(root package)의 버전을 추측할 수 없고, `composer.json`에 존재하지 않는다면, 이 변수를 셋팅함으로써 루트 패키지의 버젼을 명시 할 수 있습니다.
515 |
516 |
517 | ### COMPOSER_VENDOR_DIR - 컴포저 벤더 디렉토리
518 |
519 | 이 변수를 셋팅함으로써 컴포저가 `vendor`가 아닌 다른 디렉토리에 패키지들을 설치 할 수 있습니다.
520 |
521 | ### COMPOSER_BIN_DIR - 컴포저 바이너리 디렉토리
522 |
523 | 이 변수를 셋팅함으로써 `vender/bin`의 `bin`([Vendor Binaries](/Composer-korean-docs/doc/articles/vendor-binaries.md)) 디렉토리를 다르게 지정할 수 있습니다.
524 |
525 | ### http_proxy or HTTP_PROXY - http 프록시
526 |
527 | 만약 HTTP proxy를 통해서 컴포저를 사용하고 싶다면 `http_proxy` 또는 `HTTP_PROXY` 환경변수를 설정하여 프록시를 통한 URL 을 사용할 수 있습니다. 많은 OS에서 이 옵션을 지원하고 있습니다.
528 |
529 | 소문자로 표시된 `http_proxy` 또는 대소문자 두가지 모두 정의하는 것은 git이나 curl과 같이 `http_proxy` 소문자만 사용하는 툴들 때문이라도 권장 할만합니다. 그렇지 않다면 git proxy에서 사용하여 정의한 것처럼 사용할 수도 있습니다.
530 |
531 | `git config --global http.proxy `.
532 |
533 |
534 | ### no_proxy
535 |
536 | 프록시를 사용하고 있는 중에 특정 도메인에서 프록시를 사용하지 않기를 원한다면 `no_proxy` 변수를 사용하면 됩니다. 프록시를 사용하지 않기를 워하는 도메인을 콤마로 구분하여 셋팅하면 됩니다.
537 |
538 | 설정값은 도메인, IP 어드레스 또는 CIDR 형식의 IP 어드레스를 사용할 수 있습니다. 또한 포트에 따라서 필터링을 적용해 차단할 수도 있습니다.(예를 들어 `:80`과 같은)
539 | 만약 전체 HTTP 요청에서 프록시 사용을 하지 않기를(무시하기를) 원한다면 `*`과 같이 설정할 수도 있습니다.
540 |
541 | (역자주 : CIDR 이란 123.123.10.* 와 같이 표현될 수 있는 형식을 의미합니다.)
542 |
543 | ### HTTP_PROXY_REQUEST_FULLURI
544 |
545 | 프록시를 사용하지만 request_fullurl flag를 지원하지 않는다면 이 환경변수를 `false` 또는 `0`으로 설정하여 컴포저가 request_fulluri 옵션을 설정하는 것을 방지할 수 있습니다.
546 |
547 | ### COMPOSER_HOME 컴포저 홈 디렉토리 {#composer-home}
548 |
549 | `COMPOSER_HOME` 변수는 컴포져의 home 디렉토리를 변경할 수 있게 해줍니다. 이것은 숨겨져 있는데, 모든 프로젝트에서 공유 되는 전역(머신의 사용자) 디렉토리입니다.
550 |
551 | 기본적으로 \*nix 에서는 `/home//.composer`, OSX 에서는 `/Users//.composer` 그리고 윈도우 에서는 `C:\Users\\AppData\Roaming\Composer` 입니다.
552 |
553 |
554 | #### COMPOSER_HOME/config.json
555 |
556 | `COMPOSER_HOME`의 위치에 `config.json` 파일을 생성해 놓는다면 컴포저는 `install` 과 `update` 명령을 실행할때 당신의 프로젝트의 `composer.json` 파일과 이 파일을 합쳐서 명령을 수행합니다.
557 |
558 | 이 파일은 당신의 프로젝트에서 [configuration](/Composer-korean-docs/doc/04-schema.md#config)와 [repositories](/Composer-korean-docs/doc/05-repositories.md)를 설정하는 것을 가능하게 합니다.
559 |
560 | 만약 글로벌 설정이 _local_ 설정과 다른경우 프로젝트의 `composer.json` 안에서 설정한 _local_ 값이 항상 우선하도록 동작합니다.
561 |
562 | ### COMPOSER_CACHE_DIR
563 |
564 | `COMPOSER_CACHE_DIR` 변수는 [`cache-dir`](/Composer-korean-docs/doc/04-schema.md#config) 옵션을 설정하는 경우와 같이 컴포저의 캐시 디렉토리를 변경하는 설정입니다.
565 |
566 | 기본적으로 \*nix 와 OSC 에서는 `$COMPOSER_HOME/cache` 그리고 윈도우 에서는 `C:\Users\\AppData\Local\Composer` (또는 `%LOCALAPPDATA%/Composer`) 를 가리킵니다.
567 |
568 |
569 | ### COMPOSER_PROCESS_TIMEOUT 컴포저 대기 시간 제한
570 |
571 | 이 환경변수는 예를 들어 (git 명령어와 같은) 명령어가 종료되기 까지의 대기 시간제한을 설정합니다. 기본값은 300초(5분)입니다.
572 |
573 | ### COMPOSER_DISCARD_CHANGES
574 |
575 | 이 환경변수는 [config option](/Composer-korean-docs/doc/04-schema.md#config)와 같은 변경사항 취소를 컨트롤 합니다.
576 |
577 |
578 | ### COMPOSER_NO_INTERACTION
579 |
580 | 이 설정을 1로 설정하면, 모든 명령에서 `--no-interaction`를 사용한 것과 같이 동작하게 됩니다. 주로 빌드 스크립트나 CI 상에서 사용됩니다.
581 |
582 |
583 | ← [Libraries](/Composer-korean-docs/doc/02-libraries.md) | [Schema](/Composer-korean-docs/doc/04-schema.md) →
--------------------------------------------------------------------------------
/doc/04-schema.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "composer.json의 구조"
4 | permalink: /doc/04-schema.md/
5 | ---
6 |
7 | # composer.json의 구조
8 |
9 | 이 챕터에서는 `composer.json`에서 사용가능한 모든 항목에 대해서 설명하겠습니다.
10 |
11 | ## JSON의 구조
12 |
13 | [JSON의 구조](http://json-schema.org)는 문서화 형태로 포맷이 구성되어 있고, `composer.json`의 형태를 검증하는데도 사용할 수 있습니다. 실제로, 이것은 `validate` 명령어를 통해 사용됩니다. composer.json 의 형태는 다음과 같이 구성될 수 있습니다: [`res/composer-schema.json`](https://github.com/composer/composer/blob/master/res/composer-schema.json)
14 |
15 | ## Root 패키지
16 |
17 | 루트 패키지는 프로젝트의 루트에 있는 `composer.json`에 의해 정의 된 패키지입니다. 그것은 프로젝트의 요구사항을 정의하는 메인 `composer.json`를 의미합니다.
18 |
19 | 일부 항목들은 루트 패키지의 문맥에서만 사용됩니다. `config` 항목이 그 예입니다. 오직 루트 패키지에서만 설정할 수 있습니다. 종속패키지의 설정들은 무시되어 집니다. 이러한 특징이 `config` 항목을 `root-only`로 만듭니다.
20 |
21 | 만약 그것에 쓰이고 있는 종속 패키지중 중 하나를 복제했다면, 이제 그 패키지가 루트 패키지입니다. `composer.json`은 같지만 문맥은 다른것을 확인할 수 있습니다.
22 |
23 | > **참고:** 하나의 패키지는 문맥에 따라 루트 패키지가 될수도 있고 아닐수도 있습니다. 예를 들어, 만약 프로젝트가 `monolog` 라이브러리를 의존하고 있다면, 프로젝트가 루트 패키지 입니다. 하지만, 만약 Github로 부터 버그를 수정하기 위해 `monolog`를 복제한다면, `monolog`가 루트 패키지 입니다.
24 |
25 | ## 속성
26 |
27 | ### name - 이름
28 |
29 | 패키지의 이름입니다. 이것은 `/`로 나뉘는 벤더의 이름과 프로젝트의 이름으로 구성되어 있습니다.
30 |
31 | 예제:
32 |
33 | * monolog/monolog
34 | * igorw/event-source
35 |
36 | 퍼블리시 된 패키지(라이브러리)의 경우 필수속성입니다.
37 |
38 | ### description - 설명
39 |
40 | 패키지에 대한 짧은 설명입니다. 일반적으로 한줄 정도의 길이로 구성됩니다.
41 | 퍼블리시 된 패키지(라이브러리)의 경우 필수속성입니다.
42 |
43 | ### version - 버전
44 |
45 | 패키지의 버전을 의미합니다. 대부분의 경우에 버전은 생략할 수 있으므로 필수사항은 아닙니다.(아래 참조)
46 |
47 | 버전은 `X.Y.Z` 또는 `vX.Y.Z`의 포멧을 따라야 합니다. 선택적으로 `-dev`, `-patch`, `-alpha`, `-beta` 또는 `-RC`와 같은 접미사와 함께 쓸 수 있습니다. patch, alpha, beta 그리고 RC는 접미사로 숫자가 따라올 수 있습니다.
48 |
49 | 사용예:
50 |
51 | - 1.0.0
52 | - 1.0.2
53 | - 1.1.0
54 | - 0.2.5
55 | - 1.0.0-dev
56 | - 1.0.0-alpha3
57 | - 1.0.0-beta2
58 | - 1.0.0-RC5
59 |
60 | 패키지 저장소가 VCS 저장소 안에 VCS 태그 이름과 같이 어딘가에서 버전을 유추할 수 있다면, 이러한 경우에도 생략하는 것이 좋습니다.
61 |
62 | > **참고:** Packigist는 VCS 저장소를 사용합니다. 그래서 위의 문장은 Packigist에 대해서 아주 잘 나타내줍니다. 버전을 사용자가 직접 작성한다면 실수로 인해 언젠가 높은 확률로 문제가 발생할 소지가 있습니다.
63 |
64 | ### type
65 |
66 | 패키지의 타입을 정의합니다. 기본타입은 `library` 입니다.
67 |
68 | 패키지 타입은 커스텀 설치를 위해 사용됩니다. 당신의 패키지가 설치하기 위한 특별한 로직이 필요 하다면, 커스텀 타입을 선언해야 합니다.
69 | 예를들면 `symfony-bundle`, `wordpress-plugin` 혹은 `typo3-module`등을 사용 할수 있습니다. 이 모든 타입들은 각각의 프로젝트 마다 다르게 사용됩니다. 그리고 그 타입들은 그 타입에 맞는 설치 가능한 설치 패키지를 제공해야 합니다.
70 |
71 | composer 가 기본으로 지원하는 4가지 타입들 (설치 패키지가 필요하지 않음).
72 |
73 | - **library:** `vendor`에 파일들을 복사 하는 기본 타입입니다.
74 | - **project:** 라이브러리 가 아닌 패키지를 의미합니다. 예를 들면 [Symfony standard edition](https://github.com/symfony/symfony-standard)와 같은 쉘 어플리케이션이 있으며 [SilverStripe installer](https://github.com/silverstripe/silverstripe-installer) 같은 CMS 프로젝트가 있습니다.
75 | 혹은 패키지 처럼 완전히 분리되었을 때 사용합니다. 새로운 작업공간을 생성할때 초기설정 리스트를 제공하는 IDE들에 의해 사용되는 것을 예로 들수 있습니다.
76 | - **metapackage:** An empty package that contains requirements and will trigger
77 | their installation, but contains no files and will not write anything to the
78 | filesystem. As such, it does not require a dist or source key to be
79 | installable.
80 | - **metapackage:** requirement가 포함된 비어있는 패키지는 작동시 설치가 된다. 그러나 파일이 포함되어 있지 않으면 어떠한 내용도 파일시스템에 쓰지 않는다. 그러므로 설치시에 dist 혹은 source key 를 요구하지 않고 설치됩니다.
81 | - **composer-plugin:** `composer-plugin`타입의 패키지는 다른 커스텀 패키지들을 위해 인스톨러를 제공합니다. 자세한 내용은 [dedicated article](/Composer-korean-docs/doc/articles/custom-installers.md)에서 확인 할수 있습니다.
82 |
83 | Only use a custom type if you need custom logic during installation. It is
84 | recommended to omit this field and have it just default to `library`.
85 |
86 | 패키지를 설치하는데 커스텀 로직이 필요하면 커스텀 타입을 사용하면 됩니다. 그 외에는 타입 설정을 하지 않거나 `library` 기본 셋팅을 하는것을 추천합니다.
87 |
88 | ### keywords
89 |
90 | 패키지와 관계가 있는 키워드가 배열 형태로 선언됩니다. 이것들은 검색과 필터링에 사용 됩니다.
91 |
92 | 사용예:
93 |
94 | - logging
95 | - events
96 | - database
97 | - redis
98 | - templating
99 |
100 | 필수 항목이 아닙니다.
101 |
102 | ### homepage
103 |
104 | 프로젝트의 웹사이트 URL 입니다.
105 |
106 | 필수 항목이 아닙니다.
107 |
108 | ### time
109 |
110 | 해당 버젼의 릴리즈 날짜입니다.
111 | 반드시 `YYYY-MM-DD` 혹의 `YYYY-MM-DD HH:MM:SS` 의 형태로 사용해야 합니다.
112 |
113 | 필수 항목이 아닙니다.
114 |
115 | ### license
116 |
117 | 패키지의 라이센스를 정의 합니다. 문자 형태 혹은 배열 형태로 정의할 수 있습니다.
118 |
119 | 가장 일반적인 사용되어 지는 라이센스의 추천 항목들은 다음과 같습니다. (알파벳 순 정렬)
120 |
121 | - Apache-2.0
122 | - BSD-2-Clause
123 | - BSD-3-Clause
124 | - BSD-4-Clause
125 | - GPL-2.0
126 | - GPL-2.0+
127 | - GPL-3.0
128 | - GPL-3.0+
129 | - LGPL-2.1
130 | - LGPL-2.1+
131 | - LGPL-3.0
132 | - LGPL-3.0+
133 | - MIT
134 |
135 | 필수 항목은 아니지만 라이센스를 정의하는 것을 매우 추천합니다. 라이센스들의 기타 항목들은 [SPDX Open Source License Registry](http://www.spdx.org/licenses/) 에서 확인 할수 있습니다.
136 |
137 | 더이상 제공하지 않는 소프트웨어에 대해서는 `"proprietary"` 로 설정 하면 됩니다.
138 |
139 | 사용예:
140 |
141 | {% highlight json %}
142 | {
143 | "license": "MIT"
144 | }
145 | {% endhighlight %}
146 |
147 | 배열 형태의 선언은 여러개의 라이센스 중 선택해서 사용해야 하는 패키지에서 설정 할 수 있습니다.
148 |
149 | 다른 라이센스의 예:
150 |
151 | {% highlight json %}
152 | {
153 | "license": [
154 | "LGPL-2.1",
155 | "GPL-3.0+"
156 | ]
157 | }
158 | {% endhighlight %}
159 |
160 | 위의 형태 대신에 or로 구분된 괄호로 묶은 형태로 라이센스를 표시 할 수도 있습니다.
161 |
162 | {% highlight json %}
163 | {
164 | "license": "(LGPL-2.1 or GPL-3.0+)"
165 | }
166 | {% endhighlight %}
167 |
168 | 비슷한 경우로 결합한 형태의 라이센스가 지원 되는 경우 위의 예시에서 "or" 대신 "and" 구분자를 사용하여 설정 할 수 있습니다.
169 |
170 |
171 | ### authors - 제작자
172 |
173 | 패키지의 제작자입니다. 객체형태의 배열로 구성됩니다.
174 |
175 | 각각의 제작자를 나타내는 객체는 다음의 값들로 구성되어 집니다.
176 |
177 | * **name:** 제작자의 이름, 대게 실제 이름을 사용합니다.
178 | * **email:** 제작자의 이메일 주소.
179 | * **homepage:** 제작자 웹사이트의 주소.
180 | * **role:** 해당 프로젝트에서 제작자의 역할. (e.g. 개발자 혹은 번역가)
181 |
182 | 사용예 :
183 |
184 | {% highlight json %}
185 | {
186 | "authors": [
187 | {
188 | "name": "Nils Adermann",
189 | "email": "naderman@naderman.de",
190 | "homepage": "http://www.naderman.de",
191 | "role": "Developer"
192 | },
193 | {
194 | "name": "Jordi Boggiano",
195 | "email": "j.boggiano@seld.be",
196 | "homepage": "http://seld.be",
197 | "role": "Developer"
198 | }
199 | ]
200 | }
201 | {% endhighlight %}
202 |
203 | 필수 입력 사항은 아니지만, 가급적 입력하기를 권장합니다.
204 |
205 | ### support - 지원정보
206 |
207 | 해당 프로젝트 지원에 대한 다양한 정보를 나타냅니다.
208 |
209 | 지원 정보는 다음 내용을 따릅니다 :
210 |
211 | * **email:** 지원을 위한 이메일 주소.
212 | * **issues:** 이슈관리를 위한 URL.
213 | * **forum:** 포럼 URL.
214 | * **wiki:** 위키 URL.
215 | * **irc:** 지원을 위한 IRC 채널(irc://server/channel).
216 | * **source:** 접근 혹은 다운로드 가능한 소스의 URL.
217 |
218 | 사용예 :
219 |
220 | {% highlight json %}
221 | {
222 | "support": {
223 | "email": "support@example.org",
224 | "irc": "irc://irc.freenode.org/composer"
225 | }
226 | }
227 | {% endhighlight %}
228 |
229 | 필수 항목이 아닙니다.
230 |
231 | ### Package links (패키지 관련사항) {#package-links}
232 |
233 | 해당 내용에서는 패키지의 이름에 대응하는 [버전 제약](/Composer-korean-docs/doc/01-basic-usage.md#package-versions) 객체를 갖습니다.
234 |
235 | 사용예시
236 |
237 | {% highlight json %}
238 | {
239 | "require": {
240 | "monolog/monolog": "1.0.*"
241 | }
242 | }
243 | {% endhighlight %}
244 |
245 | 모든 패키지 관련사항은 선택사항입니다.
246 |
247 | `require`과 `require-dev`는 추가적으로 안정성(stability) 정보를 지원합니다 (root-only).
248 | 이것들은 [최소 안정성(minimum-stability)](#minimum-stability)뿐 아니라 더 제한되거나 더 확장할 수 있는 패키지의 안정성을 사용할 수 있게 해줍니다. 당신은 이러한 제약을 적용할 수 있습니다. 만약 안정적이지 않은(unstable) 패키지를 사용하길 원한다면 예시처럼 그냥 비워두시면 됩니다.
249 |
250 | 사용예 :
251 |
252 | {% highlight json %}
253 | {
254 | "require": {
255 | "monolog/monolog": "1.0.*@beta",
256 | "acme/foo": "@dev"
257 | }
258 | }
259 | {% endhighlight %}
260 |
261 | 만약 의존하고 있는 패키지들 중 하나가 안정적이지 않는 패키지라면 해당 패캐지의 확실한 안정성 플래그(stability flag)를 통해 명시적으로 표시해주어야 합니다.
262 |
263 | 사용예 :
264 |
265 | {% highlight json %}
266 | {
267 | "require": {
268 | "doctrine/doctrine-fixtures-bundle": "dev-master",
269 | "doctrine/data-fixtures": "@dev"
270 | }
271 | }
272 | {% endhighlight %}
273 |
274 | `require`과 `require-dev`는 추가적으로 개발버전을 위한 참조 값(예컨데, commit)을 명시적으로 표기할 수 있습니다. 이는 업데이트를 수행하더라도 주어진 상태를 고정할 수 있도록 해줍니다. 개발버전을 명시적으로 표기하고자 할 때 `#`의 형태로 추가하시면 됩니다.
275 |
276 | 사용예 :
277 |
278 | {% highlight json %}
279 | {
280 | "require": {
281 | "monolog/monolog": "dev-master#2eb0c0978d290a1c45346a1955188929cb4e5db7",
282 | "acme/foo": "1.0.x-dev#abc123"
283 | }
284 | }
285 | {% endhighlight %}
286 |
287 | > **주의:** 이 기능은 매우 편리해 보이지만, 근본적인 위험성 때문에 장시간동안 패키지들을 사용하는 방법이 되어서는 안됩니다. composer.json 메타데이터는 기본적으로 커밋 해쉬값보다 branch 이름으로 부터 정보를 읽어들일 것입니다. 이러한 몇가지 상황 때문에 실제적으로 사용하는 방법이라고 보기 어렵고, 가능한한 항상 Tag 가 표시된 릴리즈를 사용하도록 변경해야합니다.
288 |
289 | 패키지 정보에 대해 해당하지 않는 버전에 대응하려면 패키지 정보를 한줄로 별칭을 작성함에 따라 가능합니다. 더 많은 정보는 [별칭](/Composer-korean-docs/doc/articles/aliases.md)에서 볼 수 있습니다.
290 |
291 |
292 | #### require
293 |
294 | 해당 패키지에서 필요한 패키지들입니다. 패키지는 요구사항에 작성되지 않는 것들 외에는 설치하지 않습니다.
295 |
296 | #### require-dev (root-only)
297 |
298 | 해당 패키지를 개발하거나 테스트를 수행하는 등에 필요한 패키지들입니다. 기본으로 최상위 패키지(root package)의 개발에 필요한 요구사항을 설치하게 됩니다. `install`과 `update`는 각각 `--no-dev`라는 옵션을 지원하는데, 이는 개발에 필요한 의존성 패키지들을 설치하지 않도록 합니다.
299 |
300 | #### conflict
301 |
302 | 현재 패키지 버전에서 충돌을 일으키는 패키지들입니다. 이들은 당신의 패키지안에 설치되지 않습니다.
303 |
304 | `충돌(conflic)` 링크 내에 `<1.0 >=1.1` 처럼 작성되었을 때, 이는 1.0보다 작고, *그리고* 1.1보다 크거나 같은 이 둘을 동시에 만족하는 버전을 참고하는데 이는 반드시 충돌을 일으킬 것입니다. 그리고 이는 아마도 원하는 동작이 아닐 것입니다. 이런 상황에는 `<1.0 | >=1.1`와 같이 작성하셔야 합니다.
305 |
306 | #### replace
307 |
308 | 현재 패키지로 대체 가능한 패키지들의 리스트입니다. 이 replace 를 활용하는 경우는 패키지를 복사(fork)하고, 패키지의 고유한 버저닝과 다른 이름으로 배포할 수 있도록 합니다. 그리고 원본 패키지를 필요로하는 패키지들은 원본 패키지를 대체 할 수 있도록 복사한 패키지로도 동작이 가능하게 해줍니다.
309 |
310 | 이는 서브 패키지(sub-package)를 포함할때 매우 유용합니다. 예를 들어봅시다. 메인 symfony/symfony 패키지가 각각의 패키지로도 사용가능한 Symfony Components 전체를 포함하고 있습니다. 메인 패키지가 필요하다면 이것은 각 구성요소 모두가 대체될대까지 자동적으로 각 구성요소(components)들의 요구사항을 만족하도록 수행합니다.
311 |
312 | 위에 설명한 부가 패키지의 목적을 위해 사용을 대체할 때에는 주의가 필요합니다. 메인 패키지가 정확한 버전 또는 잘못 지정될 수 있는 버전의 서브 패키지들을 명확하게 대체하기 위해서 버전 정보로서 `self.version`을 사용하면 됩니다.
313 |
314 | #### provide
315 |
316 | 현재 패키지에서 제공하는 다른 패키지들의 리스트입니다. 이는 공통 인터페이스에서 매우 유용합니다. 패키지가 어떤 가상의 `logger` 패키지에 의존한다면, 이 logger 인터페이스를 구현하는 특정 라이브러리를 그저 `provide`안에 추가하면 됩니다.
317 |
318 | #### suggest
319 |
320 | 해당 항목은 현재 패키지와 함께하면 더 좋거나 강화할 수 있는 패키지들을 제안합니다. 이는 현재 패키지를 사용하는 사용자에게 반드시 필요하진 않지만 추가하면 좋은 패키지들의 정보를 제공하기 위해 설치 이후에 보여지는 단순한 정보입니다.
321 |
322 | 형태는 위의 패키지 관련사항의 형태와 같습니다. 다만 위의 형태와 달리 값이 버전 정보가 아니고 자유롭게 작성할 수 있습니다.
323 |
324 | 사용예:
325 |
326 | {% highlight json %}
327 | {
328 | "suggest": {
329 | "monolog/monolog": "Allows more advanced logging of the application flow"
330 | }
331 | }
332 | {% endhighlight %}
333 |
334 | ### autoload
335 |
336 | PHP 오토로더를 위한 오토로더 매핑.
337 |
338 | 현재는 [`PSR-0`](http://www.php-fig.org/psr/psr-0/) 오토로딩,
339 | [`PSR-4`](http://www.php-fig.org/psr/psr-4/) 오토로딩, 클래스맵(`classmap`) 생성, 파일(`files`) 포함을 지원합니다. PSR-4를 사용하기를 권장하며 이는 사용하기에 매우 쉽습니다. (클래스를 추가할 때마다 매번 오토로드 파일을 재생성하는 번거로움을 피할 수 있습니다.).
340 |
341 | (역자주 : PSR-0 는 현재 Deprecated 되었습니다. )
342 |
343 | #### PSR-4
344 |
345 | `psr-4`에서는 어떤 네임스페이스가 파일경로(패키지 경로에 대한 상대경로)에 대응하는지를 정의할 수 있습니다. `Foo\\Bar\\Baz`와 같이 클래스를 오토로딩할 때 `Foo\\` 네임스페이스의 전두사가 `src/` 디렉터리에 대응되어있다면, 오토로더는 `src/Bar/Baz.php` 파일을 찾을 것이고 그리고 해당 파일이 존재하면 이것을 불러올 것입니다. 예전 PSR-0에 완전히 대응되는 개념으로서 접두사(`Foo\\`)는 현재의 파일경로가 아닙니다.
346 |
347 | 네임스페이스 접두사는 비슷한 접두사들간의 충돌을 방지하기 위해 반드시 `\\`로 끝나야 합니다. 예를들어 `Foo`는 `FooBar`네임스페이스 내의 클래스에 매치 될 수 있습니다. 뒤에 백슬래쉬를 붙이는 것은 이러한 문제를 해결할 수 있습니다. `Foo\\`와 `FooBar\\`는 분명히 구분되어 집니다.
348 |
349 | PSR-4는 설치와 업데이트하는 동안 생성된 `vendor/composer/autoload_psr4.php` 파일에서 볼 수 있는 key => value로 이루어진 모든 배열 값을 참조하도록 되어 있습니다.
350 |
351 | 사용예 :
352 |
353 | {% highlight json %}
354 | {
355 | "autoload": {
356 | "psr-4": {
357 | "Monolog\\": "src/",
358 | "Vendor\\Namespace\\": ""
359 | }
360 | }
361 | }
362 | {% endhighlight %}
363 |
364 | 같은 네임스페이스의 접두사를 여러 디렉토리에서 찾을 수 있다면 다음과 같이 배열을 통해 정의할 수 있습니다.
365 |
366 |
367 | {% highlight json %}
368 | {
369 | "autoload": {
370 | "psr-4": { "Monolog\\": ["src/", "lib/"] }
371 | }
372 | }
373 | {% endhighlight %}
374 |
375 | 어떠한 네임스페이스에도 찾을 수 있는 폴백 디렉터리가 필요하면 다음과 같이 네임스페이스를 비워두면 됩니다.
376 |
377 |
378 | {% highlight json %}
379 | {
380 | "autoload": {
381 | "psr-4": { "": "src/" }
382 | }
383 | }
384 | {% endhighlight %}
385 |
386 | #### PSR-0
387 |
388 | `psr-0`에서는 어떤 네임스페이스가 파일경로(패키지 경로에 대한 상대경로)에 대응하는지를 정의할 수 있습니다. 이는 PEAR 스타일의 비-네임스페이스 규격도 지원합니다.
389 |
390 | 확실히 알아두어야 하는 것은 오토로더가 제대로 동작하기 위해서 네임스페이스는 반드시 `\\`로 끝나야 한다는 것입니다. 예를들어 `Foo`는 `FooBar`에 매치 될 수 있습니다. 뒤에 백슬래쉬를 붙이는 것은 이러한 문제를 해결할 수 있습니다. `Foo\\`와 `FooBar\\`는 분명히 구분할 수 있습니다.
391 |
392 | PSR-0는 설치와 업데이트하는 동안 생성된 `vendor/composer/autoload_namespaces.php` 파일에서 볼 수 있는 key => value로 이루어진 모든 배열 값을 참조합니다.
393 |
394 | 사용예 :
395 |
396 | {% highlight json %}
397 | {
398 | "autoload": {
399 | "psr-0": {
400 | "Monolog\\": "src/",
401 | "Vendor\\Namespace\\": "src/",
402 | "Vendor_Namespace_": "src/"
403 | }
404 | }
405 | }
406 | {% endhighlight %}
407 |
408 | 같은 네임스페이스의 접두사를 여러 디렉토리에서 찾을 수 있다면 다음과 같이 배열을 통해 정의할 수 있습니다.
409 |
410 | {% highlight json %}
411 | {
412 | "autoload": {
413 | "psr-0": { "Monolog\\": ["src/", "lib/"] }
414 | }
415 | }
416 | {% endhighlight %}
417 |
418 | PSR-0 스타일은 네임스페이스 선언을 하지 않은 클래스도 사용이 가능합니다. 이는 전역 네임스페이스에 있는 라이브러리 클래스를 사용할 때 매우 유용합니다. php 소스파일이 패키지의 기본 디렉터리에 위치한다면 다음 예제처럼 작성하실 수 있습니다.
419 |
420 | {% highlight json %}
421 | {
422 | "autoload": {
423 | "psr-0": { "UniqueGlobalClass": "" }
424 | }
425 | }
426 | {% endhighlight %}
427 |
428 | 어떠한 네임스페이스에도 대응할 수 있는 폴백 디렉터리가 필요하면 다음과 같이 네임스페이스를 비워두면 됩니다.
429 |
430 | {% highlight json %}
431 | {
432 | "autoload": {
433 | "psr-0": { "": "src/" }
434 | }
435 | }
436 | {% endhighlight %}
437 |
438 | #### Classmap
439 |
440 | `classmap`은 설치와 업데이트하는 동안 생성된 `vendor/composer/autoload_classmap.php` 파일에서 볼 수 있는 key => value로 이루어진 모든 배열 값을 참조합니다. 이러한 맵은 주어진 디렉터리와 파일에 있는 `.php`와 `.inc`파일 내에 있는 모든 클래스를 읽어들여 생성됩니다.
441 |
442 | PSR-0/4에서 지원하지 않는 모든 라이브러리의 오토로드를 사용하기 위해서 classmap을 사용할 수 있습니다. 클래스를 검색하기 위한 모든 파일과 디렉토리를 작성하시면 됩니다.
443 |
444 | 사용예 :
445 |
446 |
447 | {% highlight json %}
448 | {
449 | "autoload": {
450 | "classmap": ["src/", "lib/", "Something.php"]
451 | }
452 | }
453 | {% endhighlight %}
454 |
455 | #### Files
456 |
457 | 모든 요청에서 특정 파일을 명시적으로 사용해야할 경우 'files' 오토로드를 사용할 수 있습니다. 이것은 PHP에서 불러올 수 없는 PHP 함수들을 포함한 패키지들을 사용하는데 있어 유용할 것입니다.
458 |
459 | 사용예 :
460 |
461 | {% highlight json %}
462 | {
463 | "autoload": {
464 | "files": ["src/MyLibrary/functions.php"]
465 | }
466 | }
467 | {% endhighlight %}
468 |
469 | ### autoload-dev (root-only)
470 |
471 | 해당 항목은 개발을 목적으로한 오토로드 규칙을 정의하도록 해줍니다.
472 |
473 | 의존성 패키지로서 해당 패키지를 사용하는 다른 사람들에게는 테스트를 수행하는 클래스와 같은 경우는 메인 오토로드 규칙에 포함될 필요가 없습니다. 이러한 규칙은 오토로더를 그저 지저분하게만 할뿐입니다.
474 |
475 | 이럴 때 autoload-dev에 해당 내용을 추가하면 됩니다. 이는 유닛테스트를 위한 좋은 해결책이 될 것입니다.
476 |
477 | 사용예 :
478 |
479 | {% highlight json %}
480 | {
481 | "autoload": {
482 | "psr-4": { "MyLibrary\\": "src/" }
483 | },
484 | "autoload-dev": {
485 | "psr-4": { "MyLibrary\\Tests\\": "tests/" }
486 | }
487 | }
488 | {% endhighlight %}
489 |
490 | ### include-path
491 |
492 | > **DEPRECATED**: 해당 항목은 오래된 프로젝트(레거시 프로젝트)에서만 지원하며, 새로운 코드의 경우 오토로딩을 사용해야 합니다.
493 | > 더이상 지원하진 않지만(deprecated) 컴포저에서 사라지지는 않을 것입니다.
494 |
495 | PHP의 `include_path`에 추가되는 경로(paths)입니다.
496 |
497 | (역주: `include_path`에 추가된 경로는 프로젝트내에서 `include`, `require` 또는 `file_get_contents(.., true)` 사용시 상대경로나 절대경로를 적지 않아도 됩니다.)
498 |
499 |
500 | 사용예:
501 |
502 | {% highlight json %}
503 | {
504 | "include-path": ["lib/"]
505 | }
506 | {% endhighlight %}
507 |
508 | 필수 항목이 아닙니다.
509 |
510 | ### target-dir
511 |
512 | > **DEPRECATED**: 해당 항목은 기존의 PSR-0 스타일의 오토로딩에서 지원하며, 새로 작성하는 코드의 경우 target-dir를 사용하지 않는 PSR-4를 사용하는 편이 낫습니다. PHP 네임스페이스와 함께 PSR-0를 사용하는 프로젝트의 경우 PSR-4로 옮기는 것이 더 좋습니다.
513 |
514 | 모든 설치 경로(target)을 정의합니다.
515 |
516 | 패키지의 기본폴더(root)가 네임스페이스 정의 보다 아래에 있다면, 오토로드하지 못할 것입니다. 이 문제를 해결하기 위해선 `target-dir`을 사용해야 합니다. (역주: PSR-0은 네임스페이스 중 하위 일부만 사용하더라도 기본 네임스페이스부터 모든 폴더를 생성해주어야 합니다.)
517 |
518 | 예제는 Symfony에서 가져왔습니다. 컴포넌트를 위한 각각의 패키지가 있습니다. Yaml 컴포넌트는 `Symfony\Component\Yaml` 네임스페이스에 있습니다. 패키지의 기본폴더는 `Yaml` 디렉터리입니다. 오토로드 하려면 `vendor/symfony/yaml` 디렉터리가 아닌 `vendor/symfony/yaml/Symfony/Component/Yaml` 디렉터리에 설치되어야 합니다. 그래야 오토로더가 `vendors/symfony/yaml` 디렉터리를 로드할 수 있을 것입니다.
519 |
520 | 이렇게 하고자 할 때, `autoload`와 `target-dir`은 다음과 같이 정의하면 됩니다.
521 |
522 |
523 | {% highlight json %}
524 | {
525 | "autoload": {
526 | "psr-0": { "Symfony\\Component\\Yaml\\": "" }
527 | },
528 | "target-dir": "Symfony/Component/Yaml"
529 | }
530 | {% endhighlight %}
531 |
532 | 필수 항목이 아닙니다.
533 |
534 | ### minimum-stability (root-only) {#minimum-stability}
535 |
536 | - stability : 안정성
537 | - requirement : 요구사항
538 |
539 | 해당 옵션은 패키지에서 안정성을 통해서 패키지를 필터링하는 행동을 정의할 수 있습니다. 기본적으로 `stable`을 기본값으로 합니다. 그렇기 때문에 만약 당신이 `dev` 패키지에 의존해 있다면 당신은 충돌 또는 에러들을 피하기 위해서라도 당신의 파일에 해당(`composer.json`) 옵션을 적어주셔야 합니다.
540 |
541 | 각 패키지의 모든 버전은 이러한 안정성이 체크되는데, `minimum-stability`로 지정된 값보다 더 낮은 패키지들은 패키지들간의 의존성을 처리할 때 무시됩니다. 특정 패키지의 안정성 요구사항의 변경은 `require` 또는 `require_dev`를 통해 해결할 수 있습니다(함께보기
542 | [package links](#package-links)).
543 |
544 | 사용가능한 옵션(앞에 있는 것일 수록 안정성이 낮습니다.)으로는 `dev`, `alpha`, `beta`, `RC`, `stable`이 있습니다.
545 |
546 | ### prefer-stable (root-only)
547 |
548 | 해당 옵션을 사용하면 Composer는 사용가능한 안정적인 패키지를 찾을 수 있을 때, 더 안정적인 패키지를 선호하게 됩니다. 당신이 개발 버전을 요구하였거나 알파버전만이 사용가능하다면, 이것들은 최소 안정성(minimum-stability)에서 허락된 것 중 가능한 것을 선택할 것입니다.
549 |
550 | 해당 옵션을 사용하기 위해서 `"prefer-stable": true`를 사용하면 됩니다.
551 |
552 | ### repositories (root-only)
553 |
554 | 추가로 사용하고자 하는 패키지 저장소를 설정할 때 사용합니다.
555 |
556 | Composer는 packagist 저장소를 기본값으로 사용합니다. 그 밖에 다른 곳(packagist를 제외한)에서 제공해주는 패키지를 사용하고자 한다면 해당 저장소들을 추가로 작성하시면 됩니다.
557 |
558 | 저장소는 재귀적으로 사용할 수 없습니다. 그래서 반드시 메인이 되는 `composer.json` 파일에만 해당 내용을 추가하셔서 사용하셔야 합니다. 의존되는 패키지들의 (`vendor`안에 정의되어있는) `composer.json에서 저장소를 정의한다면 그것들은 무시됩니다.
559 |
560 | 다음 형태의 저장소를 지원합니다.
561 |
562 | * **composer:** Composer 저장소는 단순히 네트워크(HTTP, FTP, SSH)를 통해 제공되는 `packages.json`파일입니다. 그리고 이 파일은 `composer.json`의 리스트를 갖고 있습니다. 그리고 `composer.json`은 부가적으로 `dist`, 혹은 `source` 정보를 갖고 있습니다.
563 | * **vcs:** git, svn, hg와 같은 버전관리도구로 부터 패키지들을 가져올 수 있습니다.
564 | * **pear:** 해당값을 통해 pear 저장소를 프로젝트에 추가할 수 있습니다.
565 | * **package:** 만약 Composer를 지원하지 않는 프로젝트에 의존하고 싶다면, 무엇이든간에 당신은 `package` 저장소를 사용하는 패키지를 정의할 수 있습니다. 그저 단순하게 `composer.json` 객체를 나열하면 됩니다.
566 |
567 | 더 많은 정보를 얻고자 한다면 다음 링크를 참고하시면 됩니다. [Repositories](/Composer-korean-docs/doc/05-repositories.md)
568 |
569 | 사용예:
570 |
571 | {% highlight json %}
572 | {
573 | "repositories": [
574 | {
575 | "type": "composer",
576 | "url": "http://packages.example.com"
577 | },
578 | {
579 | "type": "composer",
580 | "url": "https://packages.example.com",
581 | "options": {
582 | "ssl": {
583 | "verify_peer": "true"
584 | }
585 | }
586 | },
587 | {
588 | "type": "vcs",
589 | "url": "https://github.com/Seldaek/monolog"
590 | },
591 | {
592 | "type": "pear",
593 | "url": "http://pear2.php.net"
594 | },
595 | {
596 | "type": "package",
597 | "package": {
598 | "name": "smarty/smarty",
599 | "version": "3.1.7",
600 | "dist": {
601 | "url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
602 | "type": "zip"
603 | },
604 | "source": {
605 | "url": "http://smarty-php.googlecode.com/svn/",
606 | "type": "svn",
607 | "reference": "tags/Smarty_3_1_7/distribution/"
608 | }
609 | }
610 | }
611 | ]
612 | }
613 | {% endhighlight %}
614 |
615 | > **주의:** 해당 항목의 경우 순서가 중요합니다. 컴포저는 패키지를 찾을 때 먼저 정의한 저장소부터 뒤쪽으로 순차적으로 검색하며, 가장 먼저 발견되는 패키지를 가져옵니다. Packagist를 기본값으로 사용자 정의 저장소를 덮어씌우고 싶다면 Packagist를 맨 마지막에 추가하시면 됩니다.
616 |
617 | ### config (root-only) {#config}
618 |
619 | 설정을 변경합니다. 변경한 설정은 (현재) 프로젝트에만 적용됩니다. (--global 옵션을 붙여주면 전체에도 설정됩니다.)
620 |
621 | 아래 옵션들이 설정 변경을 지원합니다.
622 |
623 | * **process-timeout:** 기본값은 `300`입니다. Composer가 실행하면서 'git clones'와 같은 일은 하면 프로세스가 죽을 수 있습니다. 그래서 연결 상태가 느리거나, vendors가 거대할 때, 기본값보다 높은 값이 필요합니다.
624 | * **use-include-path:** 기본값은 `false`입니다. 값을 true로 해준다면, autoloader가 include path에 해당하는 클래스를 PHP에서 직접 찾습니다.
625 | * **preferred-install:** 기본값은 auto이고, source, dist, auto중 선택할 수 있습니다. 이 옵션으로 선호하는 방법을 선택해 설치할 수 있습니다. (source는 git clone과 같은 소스파일을 그대로 받는 방식, dist는 zip과같이 압축된 형태로 받는 방식, auto는 어떤것이든 상관없이 받는 방식입니다.)
626 | * **store-auths:** 사용자 인증을 위한 메세지 표시로, `true` (저장), `false` (저장 안함), `prompt` (항상 물음) 중 하나를 선택할 수 있습니다. 기본값은 `prompt` 입니다.
627 | * **github-protocols:** 기본값은 `["git", "https", "ssh"]`입니다. github.com 에서 cloning 하는 프로토콜의 우선순위로, 예를 들면 HTTPS 프로토콜 우선 순위를 프록시 뒤에, 또는, 효율성이 낮은 git protocol로 사용자가 아무렇게나 재구성할 수 있습니다.
628 | * **github-oauth:** 도메인 네임과 OAuth 키에 대한 목록입니다. 예를 들어 `{"github.com": "oauthtoken"}` 에서 value인 `oauthtoken`는 github 비밀 저장소 접근 가능케 해주며, 낮은 IP 기반의 속도제한이 있는 API에 대한 접근을 회피 할 수 있도록 해줍니다. github의 OAuth 토큰을 얻는 방법을 읽어보시기 바랍니다. [Read more](/Composer-korean-docs/doc/articles/troubleshooting.md#api-rate-limit-and-oauth-tokens)
629 | * **http-basic:** 인증에 사용되는 도메인 네임과 사용자이름/비밀번호 목록입니다.`{"example.org": {"username": "alice", "password": "foo"}` 위와 같은 방식으로 작성을 하면 `alice/foo` 값이 `example.org` 에 인증을 하게 됩니다.
630 | * **vendor-dir:** 기본값은 `vendor` 입니다. 사용자는 원한다면 다른 디렉토리에 의존성을 설치할 수 있습니다. `$HOME`과 `~`는 `vendor-dir` 와 `$-dir` 이하의 모든 사용자의 홈디렉토리 경로로 대체할 수 있습니다.
631 | * **bin-dir:** 기본값은 `vendor/bin` 입니다. 만약 프로젝트가 바이너리를 include했다면, `vendor/bin`에 해당하는 디렉토리에 심볼릭링크로 가리켜지게 됩니다.
632 | * **cache-dir:** UNIX 에서의 기본값은 `$COMPOSER_HOME/cache` 이고, Window 에서의 기본값은 `C:\Users\\AppData\Local\Composer` 입니다. Composer에 의해 사용된 캐시가 모두 저장됩니다. 또한 03-CLI에서 [COMPOSER_HOME](/Composer-korean-docs/doc/03-cli.md#composer-home)를 참고하기 바랍니다.
633 | * **cache-files-dir:** 기본값은 `$cache-dir/files` 입니다. 캐시를 압축 패키지로 저장하는 경로입니다.
634 | * **cache-repo-dir:** 기본값은 `$cache-dir/repo` 입니다. `composer` 타입의 metadata 저장소와 `svn`, `github`, 그리고 `bitbucket` 타입의 VCS 저장소를 저장하는 경로입니다.
635 | * **cache-vcs-dir:** 기본값은 `$cache-dir/vcs` 입니다. VCS 저장소인 `git`/`hg` 의 metadata를 불러해서 빠른속도로 속도설치하는 VCS clones을 저장하는 경로입니다.
636 | * **cache-files-ttl:** 기본값은 `15552000` (6개월) 입니다. Composer caches가 모든 dist 패키지를 다운로드합니다. 기본값인 6개월동안 사용되지 않으면 제거합니다. 이 옵션의 기간은 사용자가 정할 수 있으며, 0으로 설정해 기능을 완전히 사용하지 않을 수 있습니다.
637 | * **cache-files-maxsize:** 기본값은 `300MiB` 입니다. Composer caches가 모든 dist 패키지를 다운로드합니다. 가비지 콜렉션이 주기적으로 실행되는 경우, 캐시의 최대 사이즈로 실행됩니다. 캐시사이즈보다 클 경우, 가장 오래전에 사용됬던 파일부터 차례대로 지우기 시작합니다.
638 | * **prepend-autoloader:** 기본값은 `true` 입니다. 만약 false 라면, 이미 존재하는 autoloader 앞에 새로운 autoloader가 추가되지 않습니다. 하지만, 이런 경우가 다른 autoloader들과의 상호작용하는 문제를 해결하기 위해 필요하기도 합니다.
639 | * **autoloader-suffix:** 기본값은 `null` 입니다. autoloader에 접미사를 붙여줍니다.(autoloader-blahblah...) null 일때는 자동으로 `autoloader` 가 생성됩니다.
640 | * **optimize-autoloader** 기본값은 `false`. `autoloader`를 dump 할 경우 항상 최적화를 시켜줍니다.
641 | * **github-domains:** 기본값은 `["github.com"]` 입니다. 사용하는 github를 사용하는 도메인 목록입니다. github Enterprise 설정에서 사용됩니다.
642 | * **github-expose-hostname:** 기본값은 `true` 입니다. 만약 false로 설정하면, github의 API를 액세스하기 위해 만든 OAuth의 토큰은 날짜 대신 장비의 호스트 이름이됩니다.
643 | * **notify-on-install:** 기본값은 `true` 입니다. 저장소의 Notification URL을 정의할 수 있으며, 저장소에 패키지가 설치될 때 알려줍니다. 이 설정을 이용해 알림을 받지 않을 수 있습니다.
644 | * **discard-changes:** 이 설정을 사용하면 비-대화식 모드에서 더러운(..) 업데이트를 처리하는 기본 스타일을 설정할 수 있습니다. `true`는 항상 vendors 안의 변경사항을 취소하는 반면, `stash`는 항상 변경된 사항을 재적용 합니다. 수정된 vendors가 적을 경우, CI서버나 배포용 스크립트에서 사용하게 됩니다.(????)
645 |
646 | 사용예:
647 |
648 | {% highlight json %}
649 | {
650 | "config": {
651 | "bin-dir": "bin"
652 | }
653 | }
654 | {% endhighlight %}
655 |
656 | > **주의:** `http-basic`, `github-oauth` 와 같이 사용자 인증 관련 옵션은 `composer.json`외에 `auth.json` 파일 내에 지정할 수 있습니다. 이러한 방법은 .gitignore에 추가할 수 있고, 개발자는 자신의 자격 증명(?)이 가능합니다.
657 |
658 | ### scripts (root-only)
659 |
660 | 설치 과정의 여러 부분들을 후킹하여 스크립트를 실행 할 수 있습니다
661 |
662 | 여기를 보시면 [Scripts](/Composer-korean-docs/doc/articles/scripts.md) 자세한 설명과 예제가 있습니다.
663 |
664 | ### extra
665 |
666 | `scripts`에서 사용하기 위한 임의의 데이터 입니다.
667 |
668 | 사실상 뭐든지 할 수 있습니다. 스크립트 내에서 액세스 하기위한 이벤트 핸들러는
669 | 아래와 같습니다:
670 |
671 | {% highlight php %}
672 | $extra = $event->getComposer()->getPackage()->getExtra();
673 | {% endhighlight %}
674 |
675 | 선택적으로 사용 가능합니다.
676 |
677 | ### bin
678 |
679 | 설정 파일을 바이너리로 처리하고, `bin-dir`이라는 심볼릭 링크로 만듭니다.
680 |
681 | 오른쪽 링크를 보시면 [Vendor Binaries](/Composer-korean-docs/doc/articles/vendor-binaries.md) 자세한 설명이 나옵니다.
682 |
683 | 선택적으로 사용 가능합니다.
684 |
685 | ### archive
686 |
687 | 패키지 압축으로 저장하기 위한 옵션을 설정합니다.
688 |
689 | 아래와 같은 옵션들이 지원됩니다.
690 |
691 | * **exclude:** 제외한 경로에 대한 패턴을 목록으로 구성됩니다.
692 | 이 패턴은 .gitignore 파일과 일치합니다.
693 | * 느낌표 ( ! ) : 일치하는 파일에 나타내는데, 이전에 exclude한 패턴에서도 나타납니다.
694 | * 슬래쉬 ( / ) : 프로젝트 시작 시의 상대경로를 나타냅니다.
695 | * 아스타 ( * ) : 디렉토리를 구분하는 구분자로 확장(사용)되지 않습니다.
696 |
697 | 예제:
698 |
699 | {% highlight json %}
700 | {
701 | "archive": {
702 | "exclude": ["/foo/bar", "baz", "/*.test", "!/foo/bar/baz"]
703 | }
704 | }
705 | {% endhighlight %}
706 |
707 | 위 예제는 `/dir/foo/bar/file`, `/foo/bar/baz`, `/file.php`,
708 | `/foo/my.test`, 4가지 경로를 include 하면, `/foo/bar/any`, `/foo/baz`, and `/my.test`, 3가지 경로를 exclude합니다.
709 |
710 | 선택적으로 사용 가능합니다.
711 |
712 | ← [Command-line interface](/Composer-korean-docs/doc/03-cli.md) | [Repositories](/Composer-korean-docs/doc/05-repositories.md) →
713 |
--------------------------------------------------------------------------------
/doc/05-repositories.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "Repositories - 저장소"
4 | permalink: /doc/05-repositories.md/
5 | ---
6 |
7 | # Repositories - 저장소
8 |
9 | 이번 챕터에서는 패키지와 저장소에 대한 개념, 어떤 종류의 저장소가 사용가능한지 그리고 이것들이 어떻게 동작하는지 설명하겠습니다.
10 |
11 | ## Concepts
12 |
13 | 먼저 실제의 다양한 형태의 저장소를 살펴 보기에 앞서, composer에 내장 된 기본 개념들을 이해할 필요가 있습니다.
14 |
15 |
16 | ### Package
17 |
18 | composer는 의존성 관리자로 패키지들을 로컬 공간에 설치합니다. 원래 패키지라는 것은 단순히 무언가를 담고 있는 디렉토리를 의미합니다. 여기에서는 PHP 코드를 의미하게 되겠지만, 이론상으로는 그 어떠한 것도 담을 수 있습니다. 그리고 패키지는 이름과 버전이 포함된 설명을 수록하고 있습니다. 이 이름과 버전은 패키지를 식별하는데 사용됩니다.
19 |
20 | 사실, composer는 내부적으로 패키지의 모든 버전들을 별도의 패키지로 간주합니다. 이러한 특징은 여러분이 composer를 사용하는 동안에는 상관 없지만, 패키지를 변경하려고 할 때는 매우 중요한 요소가 됩니다.
21 |
22 | 이름과 버전 외에도 유용한 메타데이터가 있습니다. source 정의는 대부분 설치에 관련된 정보들 입니다. 설치와 밀접하게 관련된 정보는 source 정의이고, 패키지 컨텐츠가 어디 있는지 서술하고 있습니다. 패키지 데이터는 패키지의 컨텐츠를 가리킵니다.
23 | 그리고 dist 와 source 라는 두가지의 옵션이 있습니다.
24 |
25 | **Dist:** dist 는 패키지 데이터를 압축한 묶음 버전을 말합니다. 통상적으로 릴리즈 버전, stable 릴리즈 라고도 합니다.
26 |
27 | **Source:** source 는 주로 개발용으로 사용됩니다. 보통 git과 같은 소스코드 저장소로부터 가져오게 되는데, 내려받은 패키지를 수정하고 싶을 때에는 fetch 할 수도 있습니다.
28 |
29 | 각각의 패키지는 이중 하나의 또는 두개의 옵션 모두를 지원할 수 있습니다. 사용자 제공 옵션(user-supplied options)이나 패키지 안정성과 같은 특정한 요소에 의해서 선호되는 방식으로 결정됩니다.
30 |
31 | ### Repository
32 |
33 | 저장소란, 패키지 소스를 말하며, 패키지들/버전들 의 목록을 의미합니다. composer는 프로젝트에서 필요로 하는 패키지를 찾기 위해 설정된 모든 저장소를 조사할 것입니다.
34 |
35 | composer가 기본적으로 확인하는 저장소는 Packagist 밖에 없습니다. `composer.json`를 통해서 저장소를 선언하면 프로젝트에 필요한 저장소를 더 추가할 수 있습니다.
36 |
37 | repositories 는 root 패키지에서만 유효하며, 하위 의존성 패키지에 정의된 저장소는 로드 되지 않을 것입니다. 그 이유에 대해서는 [FAQ entry](/Composer-korean-docs/doc/faqs/why-can't-composer-load-repositories-recursively.md) 문서를 읽어 보시기 바랍니다.
38 |
39 | ## Types
40 |
41 | ### Composer
42 |
43 | 주요 저장소 타입은 `composer` 저장소를 일컫습니다. 이 저장소 타입은 전체 패키지 메타데이터를 담고있는 하나의 `packages.json` 파일을 사용합니다.
44 |
45 | 이 타입은 또한, packagist가 사용하는 저장소 타입입니다. `composer` 저장소를 참조하기 위해서는, `packages.json` 파일 이전에 경로를 적용하기만 하면 됩니다. packagist의 경우, `/packages.json` 위치에 파일이 있고, 저장소 URL은 `packagist.org` 입니다.
46 | `example.org/packages.json`의 저장소 URL은 `example.org`가 될 것입니다.
47 |
48 | #### packages {#packages}
49 |
50 | 필수 필드는 `packages` 밖에 없습니다. JSON 구조는 아래와 같습니다.
51 |
52 | {% highlight json %}
53 | {
54 | "packages": {
55 | "vendor/package-name": {
56 | "dev-master": { @composer.json },
57 | "1.0.x-dev": { @composer.json },
58 | "0.0.1": { @composer.json },
59 | "1.0.0": { @composer.json }
60 | }
61 | }
62 | }
63 | {% endhighlight %}
64 |
65 | `@composer.json` 표시는 아래와 같은 최소한의 패키지 버전을 담고 있는 `composer.json`의 내용이 됩니다.
66 |
67 | * name
68 | * version
69 | * dist 혹은 source
70 |
71 | 최소 패키지는 아래와 같습니다.
72 |
73 | {% highlight json %}
74 | {
75 | "name": "smarty/smarty",
76 | "version": "3.1.7",
77 | "dist": {
78 | "url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
79 | "type": "zip"
80 | }
81 | }
82 | {% endhighlight %}
83 |
84 | 여기에 [schema](/Composer-korean-docs/doc/04-schema.md)에 있는 다른 필드 정보도 명시할 수도 있습니다.
85 |
86 | #### notify-batch
87 |
88 | `notify-batch` 필드는 사용자가 패키지를 설치할 때 매번 호출하게 될 URL을 지정할 수 있습니다.
89 | URL은 절대 경로(저장소와 동일한 도메인을 사용하게 게 됨)나 절대 표기 방식의 URL이 될 수 있습니다.
90 |
91 | 사용예:
92 |
93 | {% highlight json %}
94 | {
95 | "notify-batch": "/downloads/"
96 | }
97 | {% endhighlight %}
98 |
99 | `monolog/monolog` 패키지가 들어있는 `example.org/packages.json`이 있다고 하면, `example.org/downloads/`로 아래와 같은 JSON 요청 body를 담아 `POST` 요청을 하게 될 것입니다.
100 |
101 | {% highlight json %}
102 | {
103 | "downloads": [
104 | {"name": "monolog/monolog", "version": "1.2.1.0"},
105 | ]
106 | }
107 | {% endhighlight %}
108 |
109 | `version` 필드는 정규 표현 방식의 버전 넘버를 따릅니다.
110 |
111 | 이 필드는 선택사항 입니다.
112 |
113 | #### includes
114 |
115 | 규모가 큰 저장소를 위해 `packages.json`을 여러개의 파일로 분리하는 기능을 제공합니다.
116 | `includes` 필드를 사용하면 참조할 파일을 추가할 수 있습니다.
117 |
118 | 예제:
119 |
120 | {% highlight json %}
121 | {
122 | "includes": {
123 | "packages-2011.json": {
124 | "sha1": "525a85fb37edd1ad71040d429928c2c0edec9d17"
125 | },
126 | "packages-2012-01.json": {
127 | "sha1": "897cde726f8a3918faf27c803b336da223d400dd"
128 | },
129 | "packages-2012-02.json": {
130 | "sha1": "26f911ad717da26bbcac3f8f435280d13917efa5"
131 | }
132 | }
133 | }
134 | {% endhighlight %}
135 |
136 | 파일의 `SHA-1 sum`은 캐시되어 있다가 해시가 변경될 경우에만 재요청 하게 됩니다.
137 |
138 | 이 필드는 선택사항 입니다. 별도로 구축한 저장소를 사용한다면 아마 필요하지 않을 것입니다.
139 |
140 | #### provider-includes 와 providers-url
141 |
142 | `provider files`라고 부르는 방식은 `packagist.org`처럼 아주 큰 저장소를 사용하는 경우에 가장 선호되는 방법입니다.
143 | `provider-includes` 필드는 현재 저장소에서 제공하는 패키지 이름이 담긴 파일 정보를 나열할 수 있습니다.
144 |
145 | `providers-url` 필드는 서버에서 `provider files`를 찾는 방법을 제시합니다. 이 내용은 저장소 root에서 시작하는 절대 경로가 됩니다.
146 |
147 | 예제 :
148 |
149 | {% highlight json %}
150 | {
151 | "provider-includes": {
152 | "providers-a.json": {
153 | "sha256": "f5b4bc0b354108ef08614e569c1ed01a2782e67641744864a74e788982886f4c"
154 | },
155 | "providers-b.json": {
156 | "sha256": "b38372163fac0573053536f5b8ef11b86f804ea8b016d239e706191203f6efac"
157 | }
158 | },
159 | "providers-url": "/p/%package%$%hash%.json"
160 | }
161 | {% endhighlight %}
162 |
163 | 여기에 나오는 파일들의 내용은 아래 예제 처럼, 패키지명과 파일 무결성 검증을 위한 해시를 나열하고 있습니다.
164 |
165 | 예제 :
166 |
167 | {% highlight json %}
168 | {
169 | "providers": {
170 | "acme/foo": {
171 | "sha256": "38968de1305c2e17f4de33aea164515bc787c42c7e2d6e25948539a14268bb82"
172 | },
173 | "acme/bar": {
174 | "sha256": "4dd24c930bd6e1103251306d6336ac813b563a220d9ca14f4743c032fb047233"
175 | }
176 | }
177 | }
178 | {% endhighlight %}
179 |
180 | 위 파일은 해당 저장소에서 `providers-url`을 조회한 파일을 참조하여, `%package%`는 패키지명으로, `%hash%`는 sha256 필드로 치환한 후, acme/foo 와 acme/bar 를 찾을 수 있음을 선언하고 있습니다. 이파일들은 자체적으로 [위에서 설명](#packages)한 패키지 정의로 구성되어 있습니다.
181 |
182 | 이 필드는 선택사항 입니다. 별도로 구축한 저장소를 사용한다면 아마 필요하지 않을 것입니다.
183 |
184 | #### stream options
185 |
186 | `packages.json` 파일은 PHP stream을 통해 로드됩니다.
187 | stream에 추가 옵션을 설정하려면 `options` 파라미터를 사용합니다.
188 | PHP stream context 옵션 이라면 어떤 것이든 설정할 수 있습니다.
189 | [컨택스트 옵션과 인수](http://php.net/manual/kr/context.php)에서 더 많은 정보를 얻을 수 있습니다.
190 |
191 |
192 | ### VCS - 버전컨트롤시스템
193 |
194 | VCS는 버전컨트롤시스템을 말하며 git, svn 또는 hg와 같은 버전시스템들을 포함합니다.
195 | 컴포저는 이러한 시스템들로 부터 패키지를 설치할 수 있는 저장소 타입을 지원합니다.
196 |
197 | #### VCS 저장소에서 패키지 불러오기
198 |
199 | 몇가지 사용 예를 들어 봅시다. 가장 보편적인 예는 써드파티의 라이브러리르 포크(fork) 하여 수정하는 경우입니다. 여러분의 프로젝트가 특정한 라이브러리를 사용 하고 있고, 그 라이브러리의 일부를 변경하고자 한다면, 여러분의 프로젝트가 패치(patch)된 버전을 사용하길 원할 것입니다. (대부분의 경우와 같이) 라이브러리가 GitHub에 있다면, 손쉽게 라이브러리를 포크(fork) 하여 변경사항을 푸시(push)할 수 있습니다. 그 후에 프로젝트의 `composer.json`을 수정합니다. 이 때 할일은 여러분의 포크(fork)를 저장소로 추가하고 버전이 여러분의 별도의 브랜치를 가리키도록 수정하는 것입니다. 버전 명명 방식에 대한 더 많은 정보는 [Libraries - 라이브러리](/Composer-korean-docs/doc/02-libraries.md)에서 확인할 수 있습니다.
200 |
201 | 다음 예제는 버그를 수정하기 위해 `bugfix` 브랜치에서 monolog를 패치했다고 간주합니다:
202 |
203 | {% highlight json %}
204 | {
205 | "repositories": [
206 | {
207 | "type": "vcs",
208 | "url": "https://github.com/igorw/monolog"
209 | }
210 | ],
211 | "require": {
212 | "monolog/monolog": "dev-bugfix"
213 | }
214 | }
215 | {% endhighlight %}
216 |
217 | 이제 `php composer.phar update`를 실행하면, 패키지스트(packagist)의 `monolog/monolog` 대신에 여러분이 수정한 버전을 가져오게 됩니다.
218 |
219 | 명심할 것은 원본 패키지에서 완전히 이전하려는 것이 아니고 장기간 동안 포크(fork)를 유지하는 한 패키지의 이름을 변경해서는 안된다는 점입니다. 별도의 저장소는 패키지스트(packagist)보다 우선권을 가지기 때문에 컴포저는 원본이 아닌 당신의 패키지를 선택하게 될 것입니다. 패키지 이름은 기본 브랜치에서 가져오기 때문에 만약 패키지 이름을 변경하길 원한다면, feature 브랜치가 아닌 기본(흔히 master) 브랜치에서 변경해야 합니다.
220 |
221 | 프로젝트가 의존하는 패키지들 중에 하나가 여러분이 포크(fork)한 패키지를 필요로 한다면, 버전 제약에 그것을 맞춰주거나 또는 그러지 않도록 인라인-별칭(inline-alias)를 지정하는 것이 가능합니다. 더 많은 정보는 [앨리어스 - aliases](/Composer-korean-docs/doc/articles/aliases.md) 문서에서 볼 수 있습니다.
222 |
223 | #### 사설 저장소 사용하기
224 |
225 | 공용 저장소와 완전히 동일한 방식으로 GitHub과 BitBucket의 사설 저장소를 사용하는 것이 가능합니다.
226 |
227 | {% highlight json %}
228 | {
229 | "require": {
230 | "vendor/my-private-repo": "dev-master"
231 | },
232 | "repositories": [
233 | {
234 | "type": "vcs",
235 | "url": "git@bitbucket.org:vendor/my-private-repo.git"
236 | }
237 | ]
238 | }
239 | {% endhighlight %}
240 |
241 | 필요한 건 단지 git 클라이언트를 위한 SSH 키를 설치하는 것 뿐입니다.
242 |
243 | #### Git 대신 사용가능한 것들
244 |
245 | Git은 VCS 저장소로써 지원되는 유일한 버전컨트롤시스템이 아닙니다.
246 | 다음과 같은 저장소들이 지원되고 있습니다:
247 |
248 | * **Git:** [git-scm.com](http://git-scm.com)
249 | * **Subversion:** [subversion.apache.org](http://subversion.apache.org)
250 | * **Mercurial:** [mercurial.selenic.com](http://mercurial.selenic.com)
251 |
252 | 이들 시스템에서 패키지를 가져오기 위해서는 각각에 해당하는 클라이언트가 설치되어 있어야 합니다.
253 | 그건 좀 불편할 수도 있습니다. 이러한 이유로 GitHub과 BitBucket에 대해서는 해당 사이트에서 제공되는 API를 사용하도록 별도로 지원하여, 버전컨트롤시스템을 설치할 필요 없이 패키지를 가져올 수 있습니다.
254 | 이 VCS 저장소들은 패키지를 압축파일(zip)으로 가져갈 수 있도록 `dist`를 제공합니다.
255 |
256 | * **GitHub:** [github.com](https://github.com) (Git)
257 | * **BitBucket:** [bitbucket.org](https://bitbucket.org) (Git and Mercurial)
258 |
259 | 사용될 VCS 드라이버는 URL에 기반하여 자동으로 선택됩니다.
260 | 하지만 어떤 이유가 있어서 특정 드라이버를 명시할 필요가 있다면,
261 | 저장소 타입으로 `vcs` 대신 `git`, `svn` 또는 `hg`를 사용할 수 있습니다.
262 |
263 | GitHub 저장소에서 `no-api` 키를 `true`로 설정한다면 컴포저는 GitHub API를 사용하지 않고 다른 git 저장소와 마찬가지로 저장소를 복제(clone)할 것입니다. 그러나 `git` 드라이버를 직접 사용하는 것과는 달리,
264 | 컴포저는 여전히 GitHub의 압축파일(zip)을 사용하려고 시도할 것입니다.
265 |
266 | (역자주 : no-api 해봤는데 계속 API 에서 zip 파일 가져오려고 시도합니다. 추가 연구가 필요합니다.)
267 |
268 | #### Subversion 옵션들
269 |
270 | Subversion은 브랜치(branches)와 태그(tags) 개념을 내재하고 있지 않기 때문에, 컴포저는 기본적으로 코드가 `$url/trunk`, `$url/branches` 그리고 `$url/tags` 내에 존재한다고 간주합니다. 여러분의 저장소가 다른 디렉토리 구조를 가지고 있다면 해당 값들을 변경할 수 있습니다. 예를 들어 첫자가 대문자인 디렉토리명을 사용한다면 다음과 같이 저장소를 설정할 수 있습니다:
271 | (역자주 : 굳이 Trunk 폴더가 따로 있다면..)
272 |
273 | {% highlight json %}
274 | {
275 | "repositories": [
276 | {
277 | "type": "vcs",
278 | "url": "http://svn.example.org/projectA/",
279 | "trunk-path": "Trunk",
280 | "branches-path": "Branches",
281 | "tags-path": "Tags"
282 | }
283 | ]
284 | }
285 | {% endhighlight %}
286 |
287 | branches 또는 tags 디렉토리를 가지고 있지 않다면 `branches-path` 또는 `tags-path` 항목을 `false`로 설정하여 완전히 사용불가능하도록 할 수 있습니다.
288 |
289 | 패키지가 예를 들어 `/trunk/foo/bar/composer.json`과 `/tags/1.0/foo/bar/composer.json`처럼 서브디렉토리 내에 존재한다면, `"package-path"` 옵션을 설정함으로써 컴포저가 해당 서브디렉토리에 접근하도록 만들 수 있습니다. 이번 예의 경우 `"package-path": "foo/bar/"`이 될 것입니다.
290 |
291 | 사설 Subversion 저장소를 가지고 있다면 설정([Schema - 구조](/Composer-korean-docs/doc/04-schema.md) 참조) 내의 http-basic 섹션에서 자격증명(credential) 정보를 저장할 수 있습니다:
292 |
293 | {% highlight json %}
294 | {
295 | "http-basic": {
296 | "svn.example.org": {
297 | "username": "username",
298 | "password": "password"
299 | }
300 | }
301 | }
302 | {% endhighlight %}
303 |
304 | Subversion 클라이언트가 기본적으로 자격증명(credential)을 저장하도록 설정되어 있다면 이 자격증명(credential) 정보는 현재 사용자로 저장될 것이고 기존에 저장된 자격증명(credential) 정보는 덮어쓰여질 것입니다. 저장소 설정에서 `"svn-cache-credentials"` 옵션을 설정함으로써 이러한 행동을 변경할 수 있습니다:
305 |
306 | {% highlight json %}
307 | {
308 | "repositories": [
309 | {
310 | "type": "vcs",
311 | "url": "http://svn.example.org/projectA/",
312 | "svn-cache-credentials": false
313 | }
314 | ]
315 | }
316 | {% endhighlight %}
317 |
318 | ### PEAR
319 |
320 | 이것은 PEAR 저장소를 이용하여 특정 PEAR 채널에서 패키지들을 설치할 수 있게 해줍니다. 컴포저는 접두사 `pear-{channelName}/`를 가진 모든 패키지의 충돌을 회피 할 것입니다. 모든 패키지는 `pear-{channelAlias}/`로 별명을 달아줄 수 있습니다.
321 |
322 | 예제 `pear2.php.net` 사용:
323 |
324 | {% highlight json %}
325 | {
326 | "repositories": [
327 | {
328 | "type": "pear",
329 | "url": "http://pear2.php.net"
330 | }
331 | ],
332 | "require": {
333 | "pear-pear2.php.net/PEAR2_Text_Markdown": "*",
334 | "pear-pear2/PEAR2_HTTP_Request": "*"
335 | }
336 | }
337 | {% endhighlight %}
338 | 이 경우에 채널의 단축 이름은 `pear2`입니다. 그래서 `PEAR2_HTTP_Request` 패키지 이름은 `pear-pear2/PEAR2_HTTP_Request`에서 온 것입니다.
339 |
340 | > **참고:** `pear` 저장소는 패키지당 많은 요청을 필요로합니다.
341 | > 이때문에 설치과정을 상당히 느려지게 할 수 있습니다.
342 |
343 | #### Custom vendor alias
344 |
345 | PEAR 채널 패키지에 임의 제공자 이름을 사용 할 수있습니다.
346 |
347 | 예제:
348 |
349 | 만약 당신이 개인적인 PEAR 저장소가 있고, 그것을 VCS에 종속시키려면 composer를 이용하십시요. 당신의 PEAR 저장소는 이 패키지들을 포함합니다:
350 |
351 | * `BasePackage`가 있고,
352 | * `IntermediatePackage`가 `BasePackage`에 의존하며
353 | * `TopLevelPackage1` 와 `TopLevelPackage2`가 `IntermediatePackage`에 의존성이 있을 때
354 |
355 | 공급자의 별명이 없으면, composer는 임의의 제공자 이름으로써 PEAR 채널명을 사용합니다:
356 |
357 | * `pear-pear.foobar.repo/BasePackage`
358 | * `pear-pear.foobar.repo/IntermediatePackage`
359 | * `pear-pear.foobar.repo/TopLevelPackage1`
360 | * `pear-pear.foobar.repo/TopLevelPackage2`
361 |
362 | 향 후 당신의 PEAR패키지를 composer 저장소와 이름 구조로 이전할 계획이라면, 'foobar'제공자 이름을 채택합니다. 프로젝트가 당신의 PEAR 패키지를 사용하면 업데이트 된 패키지들이 보이지 않을 것입니다. 것들은 다른 제공자 이름을 가지고 있기 때문입니다.(`foobar/IntermediatePackage` vs `pear-pear.foobar.repo/IntermediatePackage`).
363 |
364 | 처음 PEAR 저장소가 시작할때 '제공자-별명'을 명기하면 당신은 이 문제를 피할 수 있고, 당신의 패키지 이름이 미래지향적이게 됩니다.
365 |
366 | 설명하자면, 이 예제에서는 당신의 PEAR 저장소에서 `BasePackage`, `TopLevelPackage1`와 `TopLevelPackage2` 패키지들을 가져오고 `IntermediatePackage`는 Github저장소에서 가져옵니다:
367 |
368 |
369 | {% highlight json %}
370 | {
371 | "repositories": [
372 | {
373 | "type": "git",
374 | "url": "https://github.com/foobar/intermediate.git"
375 | },
376 | {
377 | "type": "pear",
378 | "url": "http://pear.foobar.repo",
379 | "vendor-alias": "foobar"
380 | }
381 | ],
382 | "require": {
383 | "foobar/TopLevelPackage1": "*",
384 | "foobar/TopLevelPackage2": "*"
385 | }
386 | }
387 | {% endhighlight %}
388 |
389 | ### Package
390 |
391 | 만약 당신이 위에 나온 어떠한 방법으로도 컴포저를 지원하지 않는 프로젝트를 사용해야 한다면, 직접 `package` 저장소를 사용하여 패키지를 정의할 수도 있습니다.
392 |
393 | 기본적으로는, 컴포저 저장소에 있는 `packages.json` 정보와 같이 정의해 줍니다. 단 단일 패키지에 대해서 만입니다. 또, 최소한으로 필요한 항목은 `name`, `version`, `dist` 혹은 `source`입니다.
394 |
395 | 여기 smarty 템플릿 엔진을 위한 예제가 있습니다:
396 |
397 | {% highlight json %}
398 | {
399 | "repositories": [
400 | {
401 | "type": "package",
402 | "package": {
403 | "name": "smarty/smarty",
404 | "version": "3.1.7",
405 | "dist": {
406 | "url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
407 | "type": "zip"
408 | },
409 | "source": {
410 | "url": "http://smarty-php.googlecode.com/svn/",
411 | "type": "svn",
412 | "reference": "tags/Smarty_3_1_7/distribution/"
413 | },
414 | "autoload": {
415 | "classmap": ["libs/"]
416 | }
417 | }
418 | }
419 | ],
420 | "require": {
421 | "smarty/smarty": "3.1.*"
422 | }
423 | }
424 | {% endhighlight %}
425 |
426 | 일반적으로 당신이 소스 부분에서 신경을 쓰고 싶지 않다면 이것을 꼭 넣을 필요는 없습니다.
427 |
428 | > **주의**: 이 저장소 타입에는 몇가지 제약사항을 가지고 있으며, 이러한 사항들은 가급적 피해야 합니다:
429 | >
430 | > - composer는 당신이 'version' 항목을 변경하지 않으면 패키지 업데이트 하지 않을것입니다.
431 | > - composer는 커밋된 사항을 업데이트 하지 않습니다. 만약 당신이 'master'를 참조할 경우 패키지를 삭제하여
432 | > 강제 업데이트를 하고, 불안정한 lock 파일에 대하여 대처 할 필요가 있습니다.
433 |
434 | ## Hosting your own 나만의 호스팅 운영
435 |
436 | 대부분 여러분의 패키지를 패키지스트에 올리는데 집중하겠지만, 자신의 고유한 저장소를 호스팅할 수 있는 방법도 있습니다.
437 |
438 | * **Private company packages:** 만약 당신이 회사 내부적으로 composer를 사용하는 경우 여러분의 사설 패키지를 유지 할 수 있습니다.
439 | * **Separate ecosystem:** 만약 여러분의 프로젝트가 고유한 생태계를 가지고 있으며 그 패키지들이 PHP 커뮤니티에 의해서 재사용 될 수 없는 경우, 당신은 프로젝트를 패키지스트에 각각 따로 저장하고 싶을 수도 있습니다. 한 예로 워드프레스 플러그인과 같은 경우를 들 수 있겠습니다.
440 |
441 | 여러분의 고유한 패키지를 호스팅하는 경우, 최상의 성능을 위해서 저장소 타입은 `composer`으로 설정하는 것을 추천합니다.
442 |
443 | 다음의 `composer` 저장소를 만들기 위한 몇가지 도구들을 제공하고 있습니다.
444 |
445 |
446 | ### Packagist - 패키지스트
447 |
448 | 패키지스트는 기본적으로 오픈소스입니다. 이 말은 여러분이 패키지스트의 복사본을 설치하여 새롭게 운영할 수 있으며 사용할 수 있다는 뜻입니다. 이것을 정말 손쉽게 할 수 있습니다. 그러나 소-중 규모의 회사에서 몇개의 패키지들을 제공하기 위해서는 그 규모나 복잡성으로 인하여 Satis를 사용하는 것이 더 나을 것 입니다.
449 |
450 | 패키지스트는 Symfony2 어플리케이션으로 [GitHub](https://github.com/composer/packagist)에서 확인할 수 있습니다. 패키지스트는 내부적으로 컴포저를 사용하며 VCS 저장소와 composer 사용자간의 프록시 역활을 수행 합니다. 이러한 역활은 모든 VCS 패키지들의 리스트들을 보유하고, 주기적으로 정보를 갱신하며, 컴포저 저장소를 나타나게 합니다.
451 |
452 | 패키지스트를 따로 설정하고자 한다면 [packagist github repository](https://github.com/composer/packagist에 있는 지침을 따르면 됩니다.
453 |
454 | ### Satis
455 |
456 | Satis는 정적 `composer` 저장소 생성기입니다. 이것은 packagist의 초경량 정적 파일 기반 버전이라고 볼 수 있습니다.
457 |
458 | 여러분은 `composer.json`을 포함하는 저장소를 비롯하여 보통 VCS와 패키지 저장소 경로를 제공 받을 수 있습니다. 이것은 모든 패키지의 `required`와 `packages.json`의 정보를 여러분의 `composer` 저장소로 가져옵니다.
459 |
460 | 더 자세한 정보를 얻기 원하시면 [the satis GitHub repository](https://github.com/composer/satis) 혹은
461 | [Satis article](/Composer-korean-docs/doc/articles/handling-private-packages-with-satis.md)에서 확인하실 수 있습니다.
462 |
463 | (번역주 : 사내 활용용도나 기타 사용의 목적으로 비공개 패키지 저장소를 운영해야 하는 경우에 satis 를 통해서 사설 packagist 를 운영하는 효과를 낼 수 있습니다. )
464 |
465 | ### Artifact - 아티팩트
466 |
467 | 어떤 특수한 경우에는, 앞서 언급된 온라인 타입의 저장소 혹은 VCS 하나라도 구성할 수 없을 때가 있습니다. 예를 들면 artifacts를 구축하여 조직간의 라이브러리 교환을 하려고 할 때 입니다. 물론, 대부분의 경우 비공개 저장소를 운영할 것입니다. 유지 보수를 단순화 하기 위해서 비공개 패키지 폴더를 하나의 간단한 ZIP 압축파일로 `artifact` 저장소 타입을 사용 할 수 있습니다:
468 |
469 | {% highlight json %}
470 | {
471 | "repositories": [
472 | {
473 | "type": "artifact",
474 | "url": "path/to/directory/with/zips/"
475 | }
476 | ],
477 | "require": {
478 | "private-vendor-one/core": "15.6.2",
479 | "private-vendor-two/connectivity": "*",
480 | "acme-corp/parser": "10.3.5"
481 | }
482 | }
483 | {% endhighlight %}
484 |
485 | 각각의 zip 파일들은 `composer.json`의 root 폴더를 압축한 것입니다:
486 |
487 | {% highlight sh %}
488 | unzip -l acme-corp-parser-10.3.5.zip
489 |
490 | composer.json
491 | ...
492 | {% endhighlight %}
493 |
494 | 만약 그곳에 두개의 다른버전의 압축파일이 존재한다면, 그 두개 모두 가져오게됩니다. artifact 폴더에 새버전의 압축파일이 추가되고 당신이 `update`를 실행하게 되면, 그 버전도 가져오고 composer는 최신 버전으로 업데이트 할 것입니다.
495 |
496 |
497 | ## Packagist 비활성화 하기
498 |
499 | `composer.json`에 기본 Packagist 저장소를 사용하지 않도록 설정 할 수 있습니다:
500 |
501 |
502 | {% highlight json %}
503 | {
504 | "repositories": [
505 | {
506 | "packagist": false
507 | }
508 | ]
509 | }
510 | {% endhighlight %}
511 |
512 | ← [Schema](/Composer-korean-docs/doc/04-schema.md) | [Community](/Composer-korean-docs/doc/06-community.md) →
513 |
--------------------------------------------------------------------------------
/doc/06-community.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "Community - 커뮤니티"
4 | permalink: /doc/06-community.md/
5 | ---
6 |
7 | # Community - 커뮤니티
8 |
9 | 이미 많은 사람들이 컴포저를 사용하고 있으며, 그들 중 상당수는 컴포저에 기여하고 있습니다.
10 |
11 | ## Contributing - 기여하기
12 |
13 | 컴포저에 기여하기를 원한다면 다음을 확인하십시오.
14 | [README](https://github.com/composer/composer).
15 |
16 | 가이드의 가장 중요한 부분은 다음과 같습니다:
17 |
18 | > 코드에 대한 모든 기여 - 커밋 권한을 가진 사람들을 포함하여 -는 PR(pull request)를 통해서 코어 개발자가 머지(합병)하기 전에 승인과정을 거칩니다.
19 | > 이 과정은 코드가 적절한지 리뷰를 통해서 확인하기 위함입니다.
20 | > 프로젝트를 포크(Fork)하고 브랜치를 생성하여 PR(pull request)를 보내면 됩니다.
21 | >
22 | > 코드의 일관성을 확인하기 위해서 Symfony 의 [표준 코딩 규격](http://symfony.com/doc/2.0/contributing/code/standards.html)을 따라야 합니다.
23 |
24 | ## IRC / mailing list
25 |
26 | [사용자 지원을 위한](http://groups.google.com/group/composer-users) 그리고
27 | [개발자](http://groups.google.com/group/composer-dev)를 위한 메일링 리스트가 있습니다.
28 |
29 | IRC 채널은 irc.freenode.org 의 [#composer](irc://irc.freenode.org/composer)와
30 | 개발자들을 위한 [#composer-dev](irc://irc.freenode.org/composer-dev)가 있습니다.
31 |
32 | 스택 오버플로우에서 [컴포저 관련 질문들](http://stackoverflow.com/questions/tagged/composer-php)을 확인하실 수도 있습니다.
33 |
34 | ← [Repositories](/Composer-korean-docs/doc/05-repositories.md)
35 |
--------------------------------------------------------------------------------
/doc/articles/aliases.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "별칭(Aliases)"
4 | permalink: /doc/articles/aliases.md/
5 | ---
6 |
7 | # 별칭(Aliases)
8 |
9 | ## 별칭을 왜 쓰는가?
10 |
11 | VCS 저장소(Version Control System repository)를 사용하는 경우, `2.0` 또는 `2.0.x`와 같은 버전에
12 | 대해 비슷한 브랜치들을 보유하게 됩니다. `master` 브랜치를 위해서 `dev-master` 버전을 보유할
13 | 수 있고, `bugfix` 브랜치를 위해서, `dev-bugfix` 버전을 보유할 수도 있습니다.
14 |
15 | 만약 `master` 브랜치가 `1.0` ― `1.0.1`, `1.0.2`, `1.0.3`, 등 ― 개발 과정의 배포 과정에
16 | 태그 되도록 이용된다면, 이에 의존하는 어떤 패키지들은 아마도 `1.0.*` 버전을 요구하게 될 것입니다.
17 |
18 | 만약 최신 `dev-master`을 요구하는 어떤 패키지가 있다면, 다른 패키지들이 `1.0.*`에 의존하기 때문에
19 | dev 버전이 충돌을 일으키는 문제가 발생합니다. 왜냐하면 `dev-master`는 `1.0.*` 조건에는 맞지 않기
20 | 때문입니다.
21 |
22 | 이 때 별칭을 입력합니다.
23 |
24 | ## 브랜치 별칭
25 |
26 | 여러분의 VCS 저장소에 `dev-master` 브랜치가 있다고 해 봅시다. 최신의 master의 개발 버전을 원하는 경우는 상당히 흔한 경우입니다. 이를 위해서 컴포저는 당신이 `dev-master`를 `1.0.x-dev` 버전으로 별칭을 지정할 수 있도록 합니다. 이렇게 하기 위해서는 `composer.json` 중 `extra` 아래 `branch-alias` 필드를 다음과 같이 지정하면 됩니다.
27 |
28 | {% highlight json %}
29 | {
30 | "extra": {
31 | "branch-alias": {
32 | "dev-master": "1.0.x-dev"
33 | }
34 | }
35 | }
36 | {% endhighlight %}
37 |
38 | 만약 호환되지 않는(non-comparible) 버전(dev-develop 같은)을 별칭하는 경우 브랜치 이름에 `dev-` 접두사를 붙여야 합니다. 또한 호환되는 버전(즉, 숫자로 시작하고, `.x-dev`로 끝나는)을 별칭할 수 있는데 좀 더 명확한 버전을 지정해야만 합니다. 예를 들면, 1.x-dev는 1.2.x-dev 로 별칭되어야 한다.
39 |
40 | 별칭은 호환되는 개발 버전이어야 하고, `branch-alias`(브랜치 별칭)는 이 별칭이 참고하는 브랜치에 존재해야 합니다. `dev-master`에 대해서, 당신은 이 브랜치 내용을 `master` 브랜치에 커밋 해야할 필요가 있습니다.
41 |
42 | 결과적으로, 이제 어떤 패키지든 `1.0.*`를 요구하면 자연스럽게 `dev-master`를 설치하게 됩니다.
43 |
44 | 브랜치 별칭을 사용하기 위해서, 패키지 별칭을 붙인 저장소를 갖지고 있어야 합니다. 만약 유지 보수를 하지 않는 서드 파티 패키지의 한 포크(fork)를 별칭하고 싶은 경우, 다음에 설명하는 인라인 별칭(inline aliases)을 사용하면 됩니다.
45 |
46 | ## 인라인 별칭 요구하기
47 |
48 | 브랜치 별칭은 주요 개발 과정에서 훌륭하게 작동합니다. 하지만 별칭을 사용하기 위해서는 소스 저장소에 대한 제어를 할 수 있어야 하고, 버전 제어에 대한 변화를 커밋 할 수 있어야 합니다.
49 |
50 | 만약 로컬 프로젝트가 의존하는 몇몇 라이브러리에 대해 단순히 버그 수정을 원하는 경우, 이는 정말 달갑지 않습니다.
51 |
52 | 이런 이유 때문에, 패키지 내부의 `require` 와 `require-dev` 필드에 별칭 지정할 수 있습니다. `monolog/monolog` 패키지에서 버그를 발견했다고 가정해봅시다. 여러분은 깃허브에서 [Monolog](https://github.com/Seldaek/monolog) 를 복제하고, `bugfix` 라는 이름의 브랜치에 버그를 수정했습니다. 이제 여러분은 버그를 수정한 monolog 를 여러분의 로컬 프로젝트에 설치하고 싶습니다.
53 |
54 | 여러분은 `monolog/monolog` 버전 `1.*`가 필요한 `symfony/monolog-bundle`을 이용하고 있고, 그래서 여러분이 생성한 `dev-bugfix`가 해당 조건(`1.*`)에 맞길 바라고 있습니다.
55 |
56 | 여러분의 프로젝트 최상의 폴더의 `composer.json` 에 다음을 추가하기만 하면 됩니다.
57 |
58 | {% highlight json %}
59 | {
60 | "repositories": [
61 | {
62 | "type": "vcs",
63 | "url": "https://github.com/you/monolog"
64 | }
65 | ],
66 | "require": {
67 | "symfony/monolog-bundle": "2.0",
68 | "monolog/monolog": "dev-bugfix as 1.0.x-dev"
69 | }
70 | }
71 | {% endhighlight %}
72 |
73 | 이렇게 하면, 여러분의 깃허브에서 `monolog/monolog`의 `dev-bugfix` 버전을 가지고 와서 `1.0.x-dev`라고 별칭할 것입니다.
74 |
75 | > **참고:** 만약 한 패키지에서 인라인 별칭이 요구되면, 그 별칭(코드 중 `as`의 오른쪽 부분)은 버전 조건으로 사용될 것입니다.
76 | > `as` 왼쪽 부분은 무시됩니다. 결과적으로, 만약 A가 B를 요구했고, B가 `monolog/monolog`의
77 | > `dev-bugfix as 1.0.x-dev` 버전을 요구했다면, A를 설치하는 것은 B가 `1.0.x-dev`
78 | > 를 요구하게 하고, `1.0.x-dev`는 실제 `1.0`에 존재할 수도 있습니다.
79 | > 만약 존재하지 않는다면, A의 `composer.json`에서 다시-인라인-별칭(re-inline-aliased)지정을 합니다.
80 |
81 |
82 | > **참고:** 인라인 별칭은 패키지를 배포하는 경우, 특히 피해야 합니다. 만약 당신이 버그를 찾는다면, 다음 커밋에서(upstream) 에서 수정한것이 반영될 수 있도록 머지하고 이 머지된 커밋을 가져오도록 하십시오.
83 | > 이렇게 하는 것이 당신 패키지 이용자들이 문제들을 겪지 않도록 하는 것입니다.
84 |
--------------------------------------------------------------------------------
/doc/articles/custom-installers.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "Setting up and using custom installers"
4 | permalink: /doc/articles/custom-installers.md/
5 | ---
6 |
7 | # Setting up and using custom installers
8 |
9 | ## Synopsis
10 |
11 | At times it may be necessary for a package to require additional actions during
12 | installation, such as installing packages outside of the default `vendor`
13 | library.
14 |
15 | In these cases you could consider creating a Custom Installer to handle your
16 | specific logic.
17 |
18 | ## Calling a Custom Installer
19 |
20 | Suppose that your project already has a Custom Installer for specific modules
21 | then invoking that installer is a matter of defining the correct [type][1] in
22 | your package file.
23 |
24 | > _See the next chapter for an instruction how to create Custom Installers._
25 |
26 | Every Custom Installer defines which [type][1] string it will recognize. Once
27 | recognized it will completely override the default installer and only apply its
28 | own logic.
29 |
30 | An example use-case would be:
31 |
32 | > phpDocumentor features Templates that need to be installed outside of the
33 | > default /vendor folder structure. As such they have chosen to adopt the
34 | > `phpdocumentor-template` [type][1] and create a plugin providing the Custom
35 | > Installer to send these templates to the correct folder.
36 |
37 | An example composer.json of such a template package would be:
38 |
39 | {% highlight json %}
40 | {
41 | "name": "phpdocumentor/template-responsive",
42 | "type": "phpdocumentor-template",
43 | "require": {
44 | "phpdocumentor/template-installer-plugin": "*"
45 | }
46 | }
47 | {% endhighlight %}
48 |
49 | > **IMPORTANT**: to make sure that the template installer is present at the
50 | > time the template package is installed, template packages should require
51 | > the plugin package.
52 |
53 | ## Creating an Installer
54 |
55 | A Custom Installer is defined as a class that implements the
56 | [`Composer\Installer\InstallerInterface`][3] and is usually distributed in a
57 | Composer Plugin.
58 |
59 | A basic Installer Plugin would thus compose of three files:
60 |
61 | 1. the package file: composer.json
62 | 2. The Plugin class, e.g.: `My\Project\Composer\Plugin.php`, containing a class that implements `Composer\Plugin\PluginInterface`.
63 | 3. The Installer class, e.g.: `My\Project\Composer\Installer.php`, containing a class that implements `Composer\Installer\InstallerInterface`.
64 |
65 | ### composer.json
66 |
67 | The package file is the same as any other package file but with the following
68 | requirements:
69 |
70 | 1. the [type][1] attribute must be `composer-plugin`.
71 | 2. the [extra][2] attribute must contain an element `class` defining the
72 | class name of the plugin (including namespace). If a package contains
73 | multiple plugins this can be array of class names.
74 |
75 | Example:
76 |
77 | {% highlight json %}
78 | {
79 | "name": "phpdocumentor/template-installer-plugin",
80 | "type": "composer-plugin",
81 | "license": "MIT",
82 | "autoload": {
83 | "psr-0": {"phpDocumentor\\Composer": "src/"}
84 | },
85 | "extra": {
86 | "class": "phpDocumentor\\Composer\\TemplateInstallerPlugin"
87 | },
88 | "require": {
89 | "composer-plugin-api": "1.0.0"
90 | }
91 | }
92 | {% endhighlight %}
93 |
94 | ### The Plugin class
95 |
96 | The class defining the Composer plugin must implement the
97 | [`Composer\Plugin\PluginInterface`][3]. It can then register the Custom
98 | Installer in its `activate()` method.
99 |
100 | The class may be placed in any location and have any name, as long as it is
101 | autoloadable and matches the `extra.class` element in the package definition.
102 |
103 | Example:
104 |
105 | {% highlight php %}
106 | getInstallationManager()->addInstaller($installer);
120 | }
121 | }
122 | {% endhighlight %}
123 |
124 | ### The Custom Installer class
125 |
126 | The class that executes the custom installation should implement the
127 | [`Composer\Installer\InstallerInterface`][4] (or extend another installer that
128 | implements that interface). It defines the [type][1] string as it will be
129 | recognized by packages that will use this installer in the `supports()` method.
130 |
131 | > **NOTE**: _choose your [type][1] name carefully, it is recommended to follow
132 | > the format: `vendor-type`_. For example: `phpdocumentor-template`.
133 |
134 | The InstallerInterface class defines the following methods (please see the
135 | source for the exact signature):
136 |
137 | * **supports()**, here you test whether the passed [type][1] matches the name
138 | that you declared for this installer (see the example).
139 | * **isInstalled()**, determines whether a supported package is installed or not.
140 | * **install()**, here you can determine the actions that need to be executed
141 | upon installation.
142 | * **update()**, here you define the behavior that is required when Composer is
143 | invoked with the update argument.
144 | * **uninstall()**, here you can determine the actions that need to be executed
145 | when the package needs to be removed.
146 | * **getInstallPath()**, this method should return the location where the
147 | package is to be installed, _relative from the location of composer.json._
148 |
149 | Example:
150 |
151 | {% highlight php %}
152 | getPrettyName(), 0, 23);
167 | if ('phpdocumentor/template-' !== $prefix) {
168 | throw new \InvalidArgumentException(
169 | 'Unable to install template, phpdocumentor templates '
170 | .'should always start their package name with '
171 | .'"phpdocumentor/template-"'
172 | );
173 | }
174 |
175 | return 'data/templates/'.substr($package->getPrettyName(), 23);
176 | }
177 |
178 | /**
179 | * {@inheritDoc}
180 | */
181 | public function supports($packageType)
182 | {
183 | return 'phpdocumentor-template' === $packageType;
184 | }
185 | }
186 | {% endhighlight %}
187 |
188 | The example demonstrates that it is quite simple to extend the
189 | [`Composer\Installer\LibraryInstaller`][5] class to strip a prefix
190 | (`phpdocumentor/template-`) and use the remaining part to assemble a completely
191 | different installation path.
192 |
193 | > _Instead of being installed in `/vendor` any package installed using this
194 | > Installer will be put in the `/data/templates/` folder._
195 |
196 | [1]: /Composer-korean-docs/doc/04-schema.md#type
197 | [2]: /Composer-korean-docs/doc/04-schema.md#extra
198 | [3]: https://github.com/composer/composer/blob/master/src/Composer/Plugin/PluginInterface.php
199 | [4]: https://github.com/composer/composer/blob/master/src/Composer/Installer/InstallerInterface.php
200 | [5]: https://github.com/composer/composer/blob/master/src/Composer/Installer/LibraryInstaller.php
201 |
--------------------------------------------------------------------------------
/doc/articles/handling-private-packages-with-satis.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "Handling private packages with Satis or Toran Proxy"
4 | permalink: /doc/articles/handling-private-packages-with-satis.md/
5 | ---
6 |
7 | # Handling private packages with Satis or Toran Proxy
8 |
9 | # Toran Proxy
10 |
11 | [Toran Proxy](https://toranproxy.com/) is a commercial alternative to Satis offering professional support as well as a web UI to manage everything and a better integration with Composer.
12 |
13 | Toran's revenue is also used to pay for Composer and Packagist development and hosting so using it is a good way to support open source financially. You can find more information about how to set it up and use it on the [Toran Proxy](https://toranproxy.com/) website.
14 |
15 | # Satis
16 |
17 | Satis on the other hand is open source but only a static `composer`
18 | repository generator. It is a bit like an ultra-lightweight, static file-based
19 | version of packagist and can be used to host the metadata of your company's
20 | private packages, or your own. You can get it from [GitHub](http://github.com/composer/satis)
21 | or install via CLI:
22 | `php composer.phar create-project composer/satis --stability=dev --keep-vcs`.
23 |
24 | ## Setup
25 |
26 | For example let's assume you have a few packages you want to reuse across your
27 | company but don't really want to open-source. You would first define a Satis
28 | configuration: a json file with an arbitrary name that lists your curated
29 | [repositories](/Composer-korean-docs/doc/05-repositories.md).
30 |
31 | Here is an example configuration, you see that it holds a few VCS repositories,
32 | but those could be any types of [repositories](/Composer-korean-docs/doc/05-repositories.md). Then it
33 | uses `"require-all": true` which selects all versions of all packages in the
34 | repositories you defined.
35 |
36 | The default file Satis looks for is `satis.json` in the root of the repository.
37 |
38 | {% highlight json %}
39 | {
40 | "name": "My Repository",
41 | "homepage": "http://packages.example.org",
42 | "repositories": [
43 | { "type": "vcs", "url": "http://github.com/mycompany/privaterepo" },
44 | { "type": "vcs", "url": "http://svn.example.org/private/repo" },
45 | { "type": "vcs", "url": "http://github.com/mycompany/privaterepo2" }
46 | ],
47 | "require-all": true
48 | }
49 | {% endhighlight %}
50 |
51 | If you want to cherry pick which packages you want, you can list all the packages
52 | you want to have in your satis repository inside the classic composer `require` key,
53 | using a `"*"` constraint to make sure all versions are selected, or another
54 | constraint if you want really specific versions.
55 |
56 | {% highlight json %}
57 | {
58 | "repositories": [
59 | { "type": "vcs", "url": "http://github.com/mycompany/privaterepo" },
60 | { "type": "vcs", "url": "http://svn.example.org/private/repo" },
61 | { "type": "vcs", "url": "http://github.com/mycompany/privaterepo2" }
62 | ],
63 | "require": {
64 | "company/package": "*",
65 | "company/package2": "*",
66 | "company/package3": "2.0.0"
67 | }
68 | }
69 | {% endhighlight %}
70 |
71 | Once you did this, you just run `php bin/satis build `.
72 | For example `php bin/satis build config.json web/` would read the `config.json`
73 | file and build a static repository inside the `web/` directory.
74 |
75 | When you ironed out that process, what you would typically do is run this
76 | command as a cron job on a server. It would then update all your package info
77 | much like Packagist does.
78 |
79 | Note that if your private packages are hosted on GitHub, your server should have
80 | an ssh key that gives it access to those packages, and then you should add
81 | the `--no-interaction` (or `-n`) flag to the command to make sure it falls back
82 | to ssh key authentication instead of prompting for a password. This is also a
83 | good trick for continuous integration servers.
84 |
85 | Set up a virtual-host that points to that `web/` directory, let's say it is
86 | `packages.example.org`. Alternatively, with PHP >= 5.4.0, you can use the built-in
87 | CLI server `php -S localhost:port -t satis-output-dir/` for a temporary solution.
88 |
89 | ## Usage
90 |
91 | In your projects all you need to add now is your own composer repository using
92 | the `packages.example.org` as URL, then you can require your private packages and
93 | everything should work smoothly. You don't need to copy all your repositories
94 | in every project anymore. Only that one unique repository that will update
95 | itself.
96 |
97 | {% highlight json %}
98 | {
99 | "repositories": [ { "type": "composer", "url": "http://packages.example.org/" } ],
100 | "require": {
101 | "company/package": "1.2.0",
102 | "company/package2": "1.5.2",
103 | "company/package3": "dev-master"
104 | }
105 | }
106 | {% endhighlight %}
107 |
108 | ### Security
109 |
110 | To secure your private repository you can host it over SSH or SSL using a client
111 | certificate. In your project you can use the `options` parameter to specify the
112 | connection options for the server.
113 |
114 | Example using a custom repository using SSH (requires the SSH2 PECL extension):
115 |
116 | {% highlight json %}
117 | {
118 | "repositories": [
119 | {
120 | "type": "composer",
121 | "url": "ssh2.sftp://example.org",
122 | "options": {
123 | "ssh2": {
124 | "username": "composer",
125 | "pubkey_file": "/home/composer/.ssh/id_rsa.pub",
126 | "privkey_file": "/home/composer/.ssh/id_rsa"
127 | }
128 | }
129 | }
130 | ]
131 | }
132 | {% endhighlight %}
133 |
134 | > **Tip:** See [ssh2 context options](http://www.php.net/manual/en/wrappers.ssh2.php#refsect1-wrappers.ssh2-options) for more information.
135 |
136 | Example using HTTP over SSL using a client certificate:
137 |
138 | {% highlight json %}
139 | {
140 | "repositories": [
141 | {
142 | "type": "composer",
143 | "url": "https://example.org",
144 | "options": {
145 | "ssl": {
146 | "local_cert": "/home/composer/.ssl/composer.pem"
147 | }
148 | }
149 | }
150 | ]
151 | }
152 | {% endhighlight %}
153 |
154 | > **Tip:** See [ssl context options](http://www.php.net/manual/en/context.ssl.php) for more information.
155 |
156 | ### Downloads
157 |
158 | When GitHub or BitBucket repositories are mirrored on your local satis, the build process will include
159 | the location of the downloads these platforms make available. This means that the repository and your setup depend
160 | on the availability of these services.
161 |
162 | At the same time, this implies that all code which is hosted somewhere else (on another service or for example in
163 | Subversion) will not have downloads available and thus installations usually take a lot longer.
164 |
165 | To enable your satis installation to create downloads for all (Git, Mercurial and Subversion) your packages, add the
166 | following to your `satis.json`:
167 |
168 | {% highlight json %}
169 | {
170 | "archive": {
171 | "directory": "dist",
172 | "format": "tar",
173 | "prefix-url": "https://amazing.cdn.example.org",
174 | "skip-dev": true
175 | }
176 | }
177 | {% endhighlight %}
178 |
179 | #### Options explained
180 |
181 | * `directory`: the location of the dist files (inside the `output-dir`)
182 | * `format`: optional, `zip` (default) or `tar`
183 | * `prefix-url`: optional, location of the downloads, homepage (from `satis.json`) followed by `directory` by default
184 | * `skip-dev`: optional, `false` by default, when enabled (`true`) satis will not create downloads for branches
185 |
186 | Once enabled, all downloads (include those from GitHub and BitBucket) will be replaced with a _local_ version.
187 |
188 | #### prefix-url
189 |
190 | Prefixing the URL with another host is especially helpful if the downloads end up in a private Amazon S3
191 | bucket or on a CDN host. A CDN would drastically improve download times and therefore package installation.
192 |
193 | Example: A `prefix-url` of `http://my-bucket.s3.amazonaws.com` (and `directory` set to `dist`) creates download URLs
194 | which look like the following: `http://my-bucket.s3.amazonaws.com/dist/vendor-package-version-ref.zip`.
195 |
196 |
197 | ### Resolving dependencies
198 |
199 | It is possible to make satis automatically resolve and add all dependencies for your projects. This can be used
200 | with the Downloads functionality to have a complete local mirror of packages. Just add the following
201 | to your `satis.json`:
202 |
203 | {% highlight json %}
204 | {
205 | "require-dependencies": true,
206 | "require-dev-dependencies": true
207 | }
208 | {% endhighlight %}
209 |
210 | When searching for packages, satis will attempt to resolve all the required packages from the listed repositories.
211 | Therefore, if you are requiring a package from Packagist, you will need to define it in your `satis.json`.
212 |
213 | Dev dependencies are packaged only if the `require-dev-dependencies` parameter is set to true.
214 |
--------------------------------------------------------------------------------
/doc/articles/http-basic-authentication.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "HTTP basic authentication"
4 | permalink: /doc/articles/http-basic-authentication.md/
5 | ---
6 |
7 | # HTTP basic authentication
8 |
9 | 여러분의 [Satis or Toran Proxy](/Composer-korean-docs/doc/articles/handling-private-packages-with-satis.md) 서버는 HTTP 기본인증을 사용하여 보안을 강화할 수 있습니다. 프로젝트가 해당 저장소에 접근을 허용하기 위해서 컴포저에 인증에 필요한 정보를 추가해야 합니다.
10 |
11 | 가장 간단한 방법은 다음과 같이 인증정보를 저장소 설정에 함께 지정하는 것입니다:
12 |
13 | {% highlight json %}
14 | {
15 | "repositories": [
16 | {
17 | "type": "composer",
18 | "url": "http://extremely:secret@repo.example.org"
19 | }
20 | ]
21 | }
22 | {% endhighlight %}
23 |
24 | 이렇게 하면 기본적으로 제공된 저장소에서 패키지를 읽어올 때 컴포저가 자동으로 자격을 증명하면서 패키지를 가져올 수 있습니다.
25 |
26 | 함께 작업하는 모든 사람들의 경우를 고려하여 프로젝트의 composer.json에 인증정보를 입력하지 않을 수도 있습니다. 이러한 경우에 두번째 방법으로 인터렉티브 하게 인증 정보를 입력할 수 있습니다. 컴포저가 저장소에 연결시에 사용자 이름과 비밀번호를 프롬프트로 부터 입력받는 방식입니다.
27 |
28 | 인증을 위한 세 번째 방법은 `COMPOSER_HOME`또는 `composer.json` 외에 `auth.json`파일을 이용하는 것이다.
29 |
30 | 이 파일은 hostnames 설정을 따르는 각각의 사용자 이름 / 패스워드 세트를 포함하고 있습니다 . 예제 :
31 |
32 | {% highlight json %}
33 | {
34 | "basic-auth": {
35 | "repo.example1.org": {
36 | "username": "my-username1",
37 | "password": "my-secret-password1"
38 | },
39 | "repo.example2.org": {
40 | "username": "my-username2",
41 | "password": "my-secret-password2"
42 | }
43 | }
44 | }
45 | {% endhighlight %}
46 |
47 | auth.json 파일의 주요 장점은 gitignore에 포함 할 수 있다는 것입니다. 이렇게 하면 팀의 모든 개발자가 각자의 인증정보를 가질 수 있으며, 모두가 공유할 때 보다 인증의 취소도 쉽게 할 수 있습니다.
--------------------------------------------------------------------------------
/doc/articles/plugins.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "Setting up and using plugins - 플러그인 설정및 사용법"
4 | permalink: /doc/articles/plugins.md/
5 | ---
6 |
7 | # Setting up and using plugins - 플러그인 설정및 사용법
8 |
9 | ## Synopsis - 시놉시스
10 |
11 | 여러분은 컴포저의 기능을 바꾸거나 확장하고 싶을 수 있습니다. 예를들어 대다수 사용자들이 적용지 않는 특별한 환경을 원하거나 대부분의 사용자들이 원치 않는 방식으로 컴포저를 이용해 뭔가를 하려할 수도 있습니다.
12 |
13 | 이런 경우에는 플러그인을 만드는 것을 고려해 볼 수 있습니다.
14 |
15 | ## 플러그인 생성하기
16 |
17 | 플러그인은 추가 패키지에 의존성이 있을 수 있는 정규 컴포저 패키지의 일부로 코드가 탑재되어 있습니다.
18 |
19 | ### 플러그인 패키지
20 |
21 | 플러그인 패키지 파일은 다른 패키지 파일과 같지만 다음과 같은 필수요건이 있습니다.
22 |
23 | 1. [type][1] 속성은 반드시 `composer-plugin` 이어야 합니다.
24 |
25 | 2. [extra][2] 속성에는 플러그인의 클래스 (네임스페이스를 포함해서) 이름에대한 정보를 담은 `class` 요소가 반드시 포함되어야 합니다. 만약 패키지가 다수의 플러그인을 포함하는 구조라면 클래스 네임은 배열의 형태가 될 수 있습니다. 추가로 여러분의 플러그인과 호환되는 컴포저 API 버전에 대한 정보가 있는`composer-plugin-api`라는 특별한 패키지 require가 필요합니다. 현재 컴포저 플러그인 API 버전은 1.0.0 입니다.
26 |
27 | 다음 예제를 확인하십시오.
28 |
29 | {% highlight json %}
30 | {
31 | "name": "my/plugin-package",
32 | "type": "composer-plugin",
33 | "require": {
34 | "composer-plugin-api": "1.0.0"
35 | }
36 | }
37 | {% endhighlight %}
38 |
39 | ### Plugin Class - 플러그인 클래스
40 |
41 | 모든 플러그인들은 [`Composer\Plugin\PluginInterface`][3] 을 구현한 클래스가 있어야 합니다.
42 | 플러그인이 로딩된 후에 `activate()` 메소드가 [`Composer\Composer`][4] 와 [`Composer\IO\IOInterface`][5] 인스턴스를 인자로 넘겨 받아서 호출됩니다. 이 두개의 객체를 활용하여 모든 설정은 모든 내부 오브젝트와 상태를 원하는 대로 조절할 수 있게 됩니다.
43 |
44 | 예제:
45 | {% highlight php %}
46 | getInstallationManager()->addInstaller($installer);
60 | }
61 | }
62 | {% endhighlight %}
63 |
64 | ## Event Handler - 이벤트 핸들러
65 |
66 | 추가적으로 플러그인이 로딩될 때 `EventDispatcher`로 자동으로 등록되기 위해서 [`Composer\EventDispatcher\EventSubscriberInterface`][6]를 구현할 수 있습니다.
67 |
68 | 플러그인에서 가능한 이벤트들은 다음과 같습니다.
69 |
70 | * **COMMAND**, COMMAND는 플러그인을 로드하는 모든 명령들의 시작 이벤트입니다. 이는 프로그램의 입출력 오브젝트들을 액세스 할 수 있게 해줍니다.
71 | * **PRE_FILE_DOWNLOAD**, PRE_FILE_DOWNLOAD는 파일이 다운로드 되기전 발생하는 이벤트입니다. 다운로드받을 URL에서 파일을 다운받기전에`RemoteFilesystem`오브젝트를 조절하는데 사용 할 수 있습니다.
72 |
73 | > 플러그인은 또한 [script events][7]를 참고할 수 있습니다.
74 |
75 | 예제:
76 |
77 | {% highlight php %}
78 | composer = $composer;
97 | $this->io = $io;
98 | }
99 |
100 | public static function getSubscribedEvents()
101 | {
102 | return array(
103 | PluginEvents::PRE_FILE_DOWNLOAD => array(
104 | array('onPreFileDownload', 0)
105 | ),
106 | );
107 | }
108 |
109 | public function onPreFileDownload(PreFileDownloadEvent $event)
110 | {
111 | $protocol = parse_url($event->getProcessedUrl(), PHP_URL_SCHEME);
112 |
113 | if ($protocol === 's3') {
114 | $awsClient = new AwsClient($this->io, $this->composer->getConfig());
115 | $s3RemoteFilesystem = new S3RemoteFilesystem($this->io, $event->getRemoteFilesystem()->getOptions(), $awsClient);
116 | $event->setRemoteFilesystem($s3RemoteFilesystem);
117 | }
118 | }
119 | }
120 | {% endhighlight %}
121 |
122 | ## Using Plugins - 플러그인 사용하기
123 |
124 | 플러그인 패키지가 설치되고 현재 프로젝트의 목록에서 확인되는 경우 자동으로 컴포저가 시작될 때 바로 로드됩니다. 추가적으로 컴포저 전역 명령어(global command)를 사용하여 `COMPOSER_HOME` 디렉토리에 설치된 모든 플러그인 패키지들은 로컬 프로젝트의 플러그인이 로딩되기 전에 로드됩니다.
125 |
126 | > `--no-plugins` 컴포저 명령 옵션으로 모든 설치된 명령들을 비활성시킬 수 있습니다.
127 | > 이는 특히 설치나 업데이트를 할 때 플러그인들로 발생하는 에러를 방지하는데 유용합니다.
128 |
129 | [1]: /Composer-korean-docs/doc/04-schema.md#type
130 | [2]: /Composer-korean-docs/doc/04-schema.md#extra
131 | [3]: https://github.com/composer/composer/blob/master/src/Composer/Plugin/PluginInterface.php
132 | [4]: https://github.com/composer/composer/blob/master/src/Composer/Composer.php
133 | [5]: https://github.com/composer/composer/blob/master/src/Composer/IO/IOInterface.php
134 | [6]: https://github.com/composer/composer/blob/master/src/Composer/EventDispatcher/EventSubscriberInterface.php
135 | [7]: /Composer-korean-docs/doc/articles/scripts.md#event-names
--------------------------------------------------------------------------------
/doc/articles/scripts.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "Scripts - 스크립트"
4 | permalink: /doc/articles/scripts.md/
5 | ---
6 |
7 | # Scripts - 스크립트
8 |
9 | ## 스크립트(script)란?
10 |
11 | 컴포저에서 이야기 하는 스크립트(script)는 PHP의 콜백(정적 메서드로도 정의할 수 있는) 혹은 커맨드 라인 환경에서 실행가능한 명령어를 이야기 합니다. 스크립트는 사용자가 만든 패키지의 맞춤형 코드 혹은 컴포저 실행 과정 중간에 발생하는 특정 명령어를 실행하는데 굉장히 유용합니다.
12 |
13 | > **참고:** 스크립트는 루트 패키지의 `composer.json`에서만 실행가능합니다. 만약 루트 패키지의 의존성 패키지에 스크립트가 정의되어 있다면, 컴포저는 해당 스크립트를 실행하지 않습니다.
14 |
15 | ## 사용가능한 이벤트들
16 |
17 | 컴포저는 실행과정 중에 다음 정의된 이벤트들을 실행합니다:
18 |
19 | - **pre-install-cmd**: `install` 커맨드가 실행되기 전에 발생합니다.
20 | - **post-install-cmd**: `install` 커맨드가 실행된 후에 발생합니다.
21 | - **pre-update-cmd**: `update` 커맨드가 실행되기 전에 발생합니다.
22 | - **post-update-cmd**: `update` 커맨드가 실행 된 후에 발생합니다.
23 | - **pre-status-cmd**: `status` 커맨드가 실행되기 전에 발생합니다.
24 | - **post-status-cmd**: `status` 커맨드 실행 된 후에 발생합니다.
25 | - **pre-dependencies-solving**: 의존성이 해결되기 전에 발생합니다.
26 | - **post-dependencies-solving**: 의존성이 해결 된 후에 발생합니다.
27 | - **pre-package-install**: 패키지가 인스톨 되기 전에 발생합니다.
28 | - **post-package-install**: 패키지가 인스톨 된 후에 발생합니다.
29 | - **pre-package-update**: 패키지가 업데이트 되기 전에 발생합니다.
30 | - **post-package-update**: 패키지가 업데이트 된 후에 발생합니다.
31 | - **pre-package-uninstall**: 패키지가 삭제(uninstall) 되기 전에 발생합니다.
32 | - **post-package-uninstall**: 패키지가 삭제(uninstall) 된 후에 발생합니다.
33 | - **pre-autoload-dump**: 오토로더가 덤프되기 전에 발생합니다. 이는 `install`/`update` 즉 `dump-autoload`를 사용하는 커맨드를 의미합니다.
34 | - **post-autoload-dump**: 오토로더가 덤프된 후에 발생합니다. 이는 `install`/`update` 즉 `dump-autoload`를 사용하는 커맨드를 의미합니다.
35 | - **post-root-package-install**: `create-project` 커맨드가 되는 동안, 루트 패키지가 인스톨 되고 난 후에 발생합니다.
36 | - **post-create-project-cmd**: `create-project` 커맨드가 실행 된 후에 발생합니다.
37 | - **pre-archive-cmd**: `archive` 커맨드가 실행되기 전에 발생합니다.
38 | - **post-archive-cmd**: `archive` 커맨드가 실행된 후에 발생합니다.
39 |
40 | > **주의:** 컴포저는 의존하고 있는 패키지들이 `install`, `update` 전에 하는 상태에 대해서 어떠한 가정도 할 수 없습니다. 그래서 `pre-update-cmd` 혹은, `pre-install-cmd` 이벤트 훅(hook) 안에 어떤 의존성 패키지들을 필요로 하는 지에 대해 스크립트를 작성하지 않아도 됩니다. 만약 당신이 `intall`, `update`이전에 스크립트를 실행해야 한다면 당신의 루트 패키지 안에 있는 그들 각 패키지 내부에 있는지 확인하십시오.
41 |
42 | ## 스크립트 정의하기
43 |
44 | `composer.json`에 `"scripts"`라는 속성을 가질 수 있습니다. 이는 이벤트와 그 이벤트에 대응하는 스크립트의 쌍(pair)을 포함하고 있습니다. 이벤트의 스크립트는 문자열(하나의 스크립트를 위한) 또는 배열(하나 혹은 여러개의 스크립트를 위한)의 두가지 형태로 정의가능합니다.
45 |
46 | 주어진 이벤트에 대해서:
47 |
48 | - 스크립트 이벤트가 발생할 때 정의된 순서대로 실행됩니다.
49 | - 스크립트를 배열로 사용할 때, PHP 콜백과 CLI환경에서 실행가능한 커맨드 둘다 동시에 포함할 수 있습니다.
50 | - 콜백을 포함한 PHP클래스는 반드시 컴포저에서 오토로드 할 수 있어야합니다.
51 |
52 | 스크립트 정의 예제:
53 |
54 | {% highlight json %}
55 | {
56 | "scripts": {
57 | "post-update-cmd": "MyVendor\\MyClass::postUpdate",
58 | "post-package-install": [
59 | "MyVendor\\MyClass::postPackageInstall"
60 | ],
61 | "post-install-cmd": [
62 | "MyVendor\\MyClass::warmCache",
63 | "phpunit -c app/"
64 | ],
65 | "post-create-project-cmd" : [
66 | "php -r \"copy('config/local-example.php', 'config/local.php');\""
67 | ]
68 | }
69 | }
70 | {% endhighlight %}
71 |
72 | 위의 예제에서 사용한 `MyVendor\MyClass`라는 클래스는 다음의 PHP를 실행할 것입니다:
73 |
74 | {% highlight php %}
75 | getComposer();
86 | // do stuff
87 | }
88 |
89 | public static function postPackageInstall(Event $event)
90 | {
91 | $installedPackage = $event->getOperation()->getPackage();
92 | // do stuff
93 | }
94 |
95 | public static function warmCache(Event $event)
96 | {
97 | // make cache toasty
98 | }
99 | }
100 | {% endhighlight %}
101 |
102 | 이벤트가 발생 했을 때, 컴포저의 내부 이벤트 핸들러는 `Composer\Script\Event` 객체를 받습니다. 그리고 이 객체는 PHP 콜백의 첫번째 매개변수로 사용가능합니다. 이 `Event` 다음 접근자를 통해 다른 객체에 접근할 수 있습니다:
103 |
104 | - `getComposer()`: 현재 `Composer\Composer` 객체를 반환합니다.
105 | - `getName()`: 발생한 이벤트의 이름을 문자열로 반환합니다.
106 | - `getIO()`: returns the current input/output stream which implements
107 | 콘솔에 쓸 수 있는 `Composer\IO\IOInterface` 인터페이스를 구현한 현재의 인, 아웃풋 스트림을 반환합니다.
108 |
109 | ## 스크립트 직접 실행
110 |
111 | 스크립트를 직접 실행하고 싶다면 다음의 명령어를 이용하면 됩니다:
112 |
113 | {% highlight sh %}
114 | composer run-script [--dev] [--no-dev] script
115 | {% endhighlight %}
116 |
117 | 예를들어 `composer run-script post-install-cmd`은 **post-install-cmd**에 정의된 스크립트들을 실행할 것입니다.
118 |
119 |
120 | 또 `--`를 추가하여 매개변수들을 추가할 수 있습니다. 예를 들어,
121 | `composer run-script post-install-cmd -- --check`는 `--check`를 스크립트 핸들러로 보냅니다. 이러한 매개변수는 CLI 매개변수로서 사용할 수 있고, PHP 핸들러에서 `$event->getArguments()`를 통해 배열로서 불러올 수 있습니다.
122 |
123 | ## 사용자 정의 커맨드
124 |
125 | 위에 명시된 사용할 수 있는 이벤트 중에 원하는 것이 없다면 사용자 정의 스크립트를 추가할 수 있습니다. 그리고 이는 run-script를 통해서 사용가능하고, 컴포저의 자연스러운 커맨드 처럼 사용할 수 있습니다. 예를 들어 아래와 같이 단순한 내용을 정의하였다면 `composer test`라는 명령어를 통해 사용가능합니다:
126 |
127 | {% highlight json %}
128 | {
129 | "scripts": {
130 | "test": "phpunit"
131 | }
132 | }
133 | {% endhighlight %}
134 |
135 | > **참고:** 컴포저의 [bin-dir](/Composer-korean-docs/doc/articles/vendor-binaries.md#vendor-binaries를-vendor/bin-이외에-다른-곳에 설치가-가능한가요-)은 PATH의 최상위를 입력할 수 있는데, 이는 의존하고 있는 패키지들의 실행파일들을 쉽게 CLI 커맨드로서 입력할 수 있게 합니다.
136 | > 예를들어 PHPUnit을 의존하고 있고, `bin-dir`을 `scripts`라는 값으로 설정을 해놓았다면 스크립트에서 `scripts/phpunit`라는 값을 통해 접근이 가능합니다.
137 |
--------------------------------------------------------------------------------
/doc/articles/troubleshooting.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "Troubleshooting - 문제 해결"
4 | permalink: /doc/articles/troubleshooting.md/
5 | ---
6 |
7 | # Troubleshooting - 문제 해결
8 |
9 | 이 섹션은 컴포저를 사용하는 중에 나타날 수 있는 공통된 문제들을 어떻게 해결하는지에 대한 목록입니다.
10 |
11 | ## General - 일반적인 해결방법
12 |
13 | 1. 누군가에게 질문하기 전에 일반적인 문제인지 확인하기위해 [`composer diagnose`](/Composer-korean-docs/doc/03-cli.md#diagnose)를 실행하세요. (실행 후) 모든 항목이 체크 되었다면(오류가 있다고 나오지 않았다면) 다음 단계로 넘어가세요.
14 |
15 | 2. 컴포저를 사용하면서 어떠한 문제를 겪을 때에는 **최신버젼을 사용** 하길 권장합니다. 자세한 사항은 [self-update](/Composer-korean-docs/doc/03-cli.md#self-update)에서 확인하세요.
16 |
17 | 3. `curl -sS https://getcomposer.org/installer | php -- --check`라는 명령어를 통해서 인스톨러 체크를 실행하여 설치에 문제가 없는지 확인해야 합니다.
18 |
19 | 4. 문제 해결을 하는 중, 벤더의 설치된 항목이나 `composer.lock`의 엔트리에서의 발생하는 충돌문제를 배제하기 위해서는 `rm -rf vendor && composer update -v` 를 통해서 **당신이 작성한 `composer.json`에 있는 벤더들을 올바르게 (재)설치**해서 해결해야 합니다.
20 |
21 | 5. `composer clear-cache`를 실행 시켜서 Composer의 케시 데이터를 비우도록 합니다.
22 |
23 | ## Package not found : 패키지를 찾을 수 없을 경우
24 |
25 | 1. `composer.json`에 **오타가 있는지**, 혹은 저장소(repository)의 branch 나 tag 이름이 올바른지 꼼꼼히 확인하세요.
26 |
27 | 2. **[minimum-stability](/Composer-korean-docs/doc/04-schema.md#minimum-stability)를 올바르게 설정했는지** 확인해야 합니다. 문제가 발생하지 않기 위해서는, "dev"에 있는 `minimum-stability`를 설정하세요.
28 |
29 | 3. **[Packagist](https://packagist.org/)에 존재하지 않는** 페키지들은 항상 **루트페키지 안에서 정의되어야** 합니다.(해당 페키지는 모든 벤더에 의존됩니다.)
30 |
31 | 4. 당신의 프로젝트 저장소의 tag 와 branch들 모두 **같은 벤더 이름과 패키지 이름**을 사용하세요, 특히 `replace`를 사용하거나 서드파티의 패키지를 포크해서 유지보수 할 경우도 포함됩니다.
32 |
33 | 5. 만약 최근에 출시된 버전의 패키지로 바로 업데이트를 한다면, 패키지스트의 패키지를 컴포져에서 확인하는데 최대 1분의 시간이 걸린다는 것을 유념하고 있어야 합니다.
34 |
35 | ## Package not found on travis-ci.org : travis-ci.org에서 패키지를 찾을 수 없는 경우
36 |
37 | 1. 우선 위의 ["Package not found"](#package-not-found)의 항목을 확인하세요.
38 |
39 | 2. 만약 테스트 되어진 패키지가 해당 패키지의 의존 패키지들 중 하나의 의존성일 경우(["순환 종속성"](http://en.wikipedia.org/wiki/Circular_dependency):서로가 서로를 의존하는 관계), 문제가 되는 것은 아마도 컴포저가 패키지의 버전을 정확하게 찾아내지 못하게 되는 부분입니다. 이것이 git clone이라면, 보통 올바르거나 컴포저가 현재 버전을 잘 찾아낼 것이지만, travis는 얕은 복사를 하기 때문에 보통 pull request나 branch들을 구성하는 작업의 테스트를 진행할 경우 실패 할 수 있습니다.
40 |
41 | 가장 좋은 방법은 여려분이 COMPOSER_ROOT_VERSION라는 환경변수를 통해 버전을 정의하는 것입니다. 여러분은 그런 정보들을 `dev-master`에서 설정할 수 있는데, 예를 들자면 루트 패키지의 버전을 `dev-master`로 정의할 수 있습니다.
42 |
43 | 사용법 : `before_script: COMPOSER_ROOT_VERSION=dev-master composer install` 컴포저를 부르기 위한 변수를 보냅니다.
44 |
45 | ## Need to override a package version : 패키지 버전을 덮어 씌우는 것이 필요할 경우
46 |
47 | 예를 들면 여러분의 프로젝트가 차래로 패키지 B의 특별한 버전을 의존하는(0.1 이라 하자.) 패키지 A에 의존하고 당신은 다른 버전의 패키지 B가 필요하다하면 - 버전 0.11과 같은.
48 |
49 | 당신은 별칭 기능을 이용하여 버전 0.11을 0.1로 고칠 수 있습니다.
50 |
51 | composer.json:
52 |
53 | {% highlight json %}
54 | {
55 | "require": {
56 | "A": "0.2",
57 | "B": "0.11 as 0.1"
58 | }
59 | }
60 | {% endhighlight %}
61 |
62 | [aliases](/Composer-korean-docs/doc/articles/aliases.md)에서 더 자세한 내용을 확인하세요.
63 |
64 | ## Memory limit errors : 메모리 제한 오류의 경우
65 |
66 | 만약 컴포저가 어떠한 명령의 실행중에서 메모리 에러를 보여준다면:
67 |
68 | `PHP Fatal error: Allowed memory size of XXXXXX bytes exhausted <...>`
69 |
70 | PHP의 `memory_limit` 부분을 올려주세요.
71 |
72 | > **필기:** 컴포저에서는 자체적으로 `memory_limit`를 `512M`만큼 올려줍니다.
73 | > 만약에 컴포저를 사용하는 도중에 메모리 문제가 발생한다면, [문제 보고 만들기](https://github.com/composer/composer/issues)를 만들어주셔야 우리가 그 문제를 자세히 확인할 수 있습니다.
74 |
75 | 현재 `memory_limit` 설정값을 확인하기 위해서는, 아래와 같이 실행하세요:
76 |
77 | {% highlight sh %}
78 | php -r "echo ini_get('memory_limit').PHP_EOL;"
79 | {% endhighlight %}
80 |
81 | `php.ini` 파일을 수정하여 메모리 제한 값을 올리는 일을 하세요. (ex. Debian계열의 시스템에서는 `/etc/php5/cli/php.ini` 입니다.):
82 |
83 | {% highlight ini %}
84 | ; Use -1 for unlimited or define an explicit value like 512M
85 | memory_limit = -1
86 | {% endhighlight %}
87 |
88 | 혹은 커맨드 라인 문법으로 제한을 올릴 수 있습니다:
89 |
90 | {% highlight sh %}
91 | php -d memory_limit=-1 composer.phar <...>
92 | {% endhighlight %}
93 |
94 |
95 | ## "The system cannot find the path specified" (Windows) : 시스템이 명시된 경로를 찾을 수 없다고 하는 경우. (Windows만 해당.)
96 |
97 | 1. regedit을 실행합니다. (시작 -> 실행 : regedit 입력)
98 | 2. `HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor` 혹은 `HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Command Processor`안에 있는 `AutoRun`을 찾습니다.
99 | 3. 만약 위의 것이 어떠한 경로에도 존재하지 않는 파일이라고 확인하고, 만약 그 경우라면 그냥 그것들을 삭제 하세요.
100 |
101 |
102 | ## API rate limit and OAuth tokens (API rate limit 과 OAuth 토큰) {#api-rate-limit-and-oauth-tokens}
103 |
104 | Github의 API에 대한 접근 횟수 제한 때문에 컴포저가 인증을 위해 당신의 username(ID)와 passoword를 요구할 수 있습니다만 그대로 진행하시면 됩니다.
105 |
106 | 만약에 컴포저에서 당신의 Github 인증제공을 선호하지 않으시면 토큰을 이용하여 수동으로 인증하실 수 있습니다. 다음의 절차를 따라가세요.
107 |
108 | 1. GitHub에서 OAuth 토큰을 [생성](https://github.com/settings/applications)하세요. [이곳](https://github.com/blog/1509-personal-api-tokens) 더 읽어보세요.
109 |
110 | 2. `composer config -g github-oauth.github.com `을 실행 해서 설정값에 OAuth 토큰을 추가하세요.
111 |
112 | 이제 컴포저는 인증을 묻는 일 없이 설치와 업데이트가 진행 됩니다.
113 |
114 | ## proc_open(): fork failed errors - 포크 실패 에러
115 |
116 | 만약 컴포저가 다른 명령어를 사용 중 proc_open() fork failed을 보여줄 경우에는:
117 |
118 | `PHP Fatal error: Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar`
119 |
120 | 이 경우 VPS가 out of memony를 실행하면서 Swap 가능한 공간이 없기 때문에 발생할 수 있습니다.
121 |
122 | {% highlight sh %}
123 | free -m
124 |
125 | total used free shared buffers cached
126 | Mem: 2048 357 1690 0 0 237
127 | -/+ buffers/cache: 119 1928
128 | Swap: 0 0 0
129 | {% endhighlight %}
130 |
131 | 당신이 Swap (용량)을 사용 할 수 있도록 가능하게 하는 예제 입니다:
132 |
133 | {% highlight sh %}
134 | /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
135 | /sbin/mkswap /var/swap.1
136 | /sbin/swapon /var/swap.1
137 | {% endhighlight %}
138 |
--------------------------------------------------------------------------------
/doc/articles/vendor-binaries.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "Vendor binaries 와 `vendor/bin` 디렉토리"
4 | permalink: /doc/articles/vendor-binaries.md/
5 | ---
6 |
7 | # Vendor binaries 와 `vendor/bin` 디렉토리
8 |
9 | ## vendor binary란?
10 |
11 | 사용자가 컴포저 패키지 인스톨을 통해서 받은 패키지가 포함하고 있는 커맨드 라인 스크립트같은 것들을 vendor binary라고 합니다.
12 |
13 | 만약 패키지가 구동에 필요로 하지 않는 (빌드나, 컴파일 스크립트와 같은) 다른 스크립트들을 포함하고 있다면 이러한 것들은 벤더 바이너리에 위치하지 않도록 해야합니다.
14 |
15 |
16 | ## 어떻게 설정하는가?
17 |
18 | Vendor binaries는 `composer.json`에 `bin` 항목을 추가하여 설정할 수 있습니다. 프로젝트에 여러개의 파일을 필요로 한다면 배열 형식으로 설정하면 됩니다.
19 |
20 | {% highlight json %}
21 | {
22 | "bin": ["bin/my-script", "bin/my-other-script"]
23 | }
24 | {% endhighlight %}
25 |
26 | ## composer.json 파일에 vendor binary 를 정의하는 것은 무엇을 의미하나요?
27 |
28 | 컴포저가 프로젝트와 해당 프로젝트가 의존하는 프로젝트들을 설치 할 때 패키지의 바이너리들을 `vendor/bin` 디렉토리에 설
29 | 치하도록 합니다.
30 |
31 | 이렇게 하면 실행하려는 스크립트들을 손쉽게 확인할 수 있게 합니다. 그렇지 않으면 이 파일들은 `vendor/` 디렉토리 깊숙히 위치하고 있기 때문에 알기가 어렵습니다.
32 |
33 |
34 | ## composer.json 파일에 vendor binaries 를 정의하면 컴포저가 실행될 때 어떤 일이 일어 나나요?
35 |
36 | 패키지가 직접 지정하는 바이너리를 위해서는, 아무일도 일어나지 않습니다.
37 |
38 |
39 | ## vendor binar가 설정된 composer.json 을 기반으로 컴포저가 구동될 때 어떤 일이 일어 나나요?
40 |
41 | 컴포저는 모든 의존 패키지들에 정의 된 바이너리를 찾습니다. 그 후 `vendor/bin` 디렉토리에 각각의 의존 패키지들의 바이너리 에 연결되는 심볼릭 링크가 생성됩니다.
42 |
43 | `my-vendor/project-a` 패키지가 다음과 같은 바이너리를 가지고 있다고 해봅시다:
44 |
45 | {% highlight json %}
46 | {
47 | "name": "my-vendor/project-a",
48 | "bin": ["bin/project-a-bin"]
49 | }
50 | {% endhighlight %}
51 |
52 | 이 `composer.json`을 기반으로 `composer install` 이 실행될 때에는 `bin/project-a-bin` 과 관련된 어떤 것도 싱행되지는 않을 것입니다.
53 |
54 | 하지만 `my-vendor/project-b` 프로젝트가 다음과 같이 의존성을 가지고 있다고 해봅시다:
55 |
56 |
57 | {% highlight json %}
58 | {
59 | "name": "my-vendor/project-b",
60 | "require": {
61 | "my-vendor/project-a": "*"
62 | }
63 | }
64 | {% endhighlight %}
65 |
66 | 이 `composer.json`을 기반으로 `composer install`이 실행 될 때에는 project-b의 의존성을 체크하고 `vendor/bin` 을 설치하게 됩니다.
67 |
68 | 이 경우 컴포저는 `vendor/bin/project-a-bin`로 연결이 가능한 `vendor/my-vendor/project-a/bin/project-a-bin`를 생성합니다. 유닉스-like 플랫폼인 경우, 이 연결은 심폴릭 링크로 구성됩니다.
69 |
70 |
71 | ## 윈도우와 .bat 확장자 파일의 경우는 어떻습니까?
72 |
73 | 패키지들은 컴포저에 의해서 전적으로 관리되며 윈도우에서의 호환성을 위해서 특별히 `.bat`확장자 파일을 *포함할 필요는 없습니다.* 컴포저는 윈도우 환경에서 구동되기 위해서 바이너리들의 설치를 특별한 방법으로 처리합니다.
74 |
75 | * 각 바이너리를 참조하기 위해서 `.bat` 파일이 자동으로 생성됩니다.
76 | * 바이너리와 동일한 이름을 가지는 유닉스 스타일의 프록시 파일이 생성됩니다. (Cygwin 또는 Git Bash 등에서 유용한)
77 |
78 |
79 | 컴포저를 포함하지 않은 워크플로우를 지원해야 하는 패키지의 경우 커스텀 `.bat` 파일을 지원할 수도 있습니다.
80 | 이러한 경우 패키지는 바이너리의 표시로 `.bat` 파일을 지정하지 않아야 합니다.
81 |
82 |
83 | ## vendor binaries를 vendor/bin 이외에 다른 곳에 설치가 가능한가요?
84 |
85 | 물론 가능하며, 다른곳에 위치하기 위한 2가지 방법이 존재합니다.
86 |
87 | 1. `composer.json` 파일에 `bin-dir` 설정을 추가하거나 `composer.json`
88 | 1. `COMPOSER_BIN_DIR` 환경변수를 설정하는 방법입니다.
89 |
90 | 설정을 지정한 예는 다음과 같은 형태일 것입니다. :
91 |
92 | {% highlight json %}
93 | {
94 | "config": {
95 | "bin-dir": "scripts"
96 | }
97 | }
98 | {% endhighlight %}
99 |
100 | `composer.json`에 위와 같이 지정하고 `composer install`을 실행하면 `vendor/bin/` 대신에 `scripts/` 폴더에 vendor binaries 를 설치합니다.
101 |
102 | `bin-dir`을 `./`와 같이 설정하여 프로젝트 루트 디렉토리로 지정할 수도 있습니다.
103 |
--------------------------------------------------------------------------------
/doc/dev/DefaultPolicy.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "Default Solver Policy"
4 | permalink: /doc/dev/DefaultPolicy.md/
5 | ---
6 |
7 | # Default Solver Policy
8 |
9 | A solver policy defines behaviour variables of the dependency solver. It decides
10 | which versions are considered newer than others, which packages should be
11 | preferred over others and whether operations like downgrades or uninstall are
12 | allowed.
13 |
14 | ## Selection of preferred Packages
15 |
16 | The following describe package pool situations with user requests and the
17 | resulting order in which the solver will try to install them.
18 |
19 | The rules are to be applied in the order of these descriptions.
20 |
21 | ### Package versions
22 |
23 | Packages: Av1, Av2, Av3
24 |
25 | * Installed: Av2
26 |
27 | Request: install A
28 |
29 | * (Av3)
30 |
31 | ### Repository priorities
32 |
33 | Packages Repo1.Av1, Repo2.Av1
34 |
35 | * priority(Repo1) >= priority(Repo2) => (Repo1.Av1, Repo2.Av1)
36 | * priority(Repo1) < priority(Repo2) => (Repo2.Av1, Repo1.Av1)
37 |
38 | ### Virtual Packages (provides)
39 |
40 | Packages Av1, Bv1
41 |
42 | * Av1 provides Xv1
43 | * Bv1 provides Xv1
44 |
45 | Request: install X
46 |
47 | * priority(Av1.repo) >= priority(Bv1.repo) => (Av1, Bv1)
48 | * priority(Av1.repo) < priority(Bv1.repo) => (Bv1, Av1)
49 |
50 | ### Package replacements
51 |
52 | Packages: Av1, Bv2
53 |
54 | * Bv2 replaces Av1
55 |
56 | Request: install A
57 |
58 | * priority(Av1.repo) >= priority(Bv2.repo) => (Av1, Bv2)
59 | * priority(Av1.repo) < priority(Bv2.repo) => (Bv2, Av1)
60 |
61 | Bv2 version is ignored, only the replacement version for A matters.
62 |
--------------------------------------------------------------------------------
/doc/faqs/how-do-i-install-a-package-to-a-custom-path-for-my-framework.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "How do I install a package to a custom path for my framework?"
4 | permalink: /doc/faqs/how-do-i-install-a-package-to-a-custom-path-for-my-framework.md/
5 | ---
6 |
7 | # How do I install a package to a custom path for my framework?
8 |
9 | Each framework may have one or many different required package installation
10 | paths. Composer can be configured to install packages to a folder other than
11 | the default `vendor` folder by using
12 | [composer/installers](https://github.com/composer/installers).
13 |
14 | If you are a **package author** and want your package installed to a custom
15 | directory, simply require `composer/installers` and set the appropriate `type`.
16 | This is common if your package is intended for a specific framework such as
17 | CakePHP, Drupal or WordPress. Here is an example composer.json file for a
18 | WordPress theme:
19 |
20 | ```json
21 | {
22 | "name": "you/themename",
23 | "type": "wordpress-theme",
24 | "require": {
25 | "composer/installers": "~1.0"
26 | }
27 | }
28 | ```
29 |
30 | Now when your theme is installed with Composer it will be placed into
31 | `wp-content/themes/themename/` folder. Check the
32 | [current supported types](https://github.com/composer/installers#current-supported-types)
33 | for your package.
34 |
35 | As a **package consumer** you can set or override the install path for a package
36 | that requires composer/installers by configuring the `installer-paths` extra. A
37 | useful example would be for a Drupal multisite setup where the package should be
38 | installed into your sites subdirectory. Here we are overriding the install path
39 | for a module that uses composer/installers:
40 |
41 | ```json
42 | {
43 | "extra": {
44 | "installer-paths": {
45 | "sites/example.com/modules/{$name}": ["vendor/package"]
46 | }
47 | }
48 | }
49 | ```
50 |
51 | Now the package would be installed to your folder location, rather than the default
52 | composer/installers determined location.
53 |
54 | > **Note:** You cannot use this to change the path of any package. This is only
55 | > applicable to packages that require `composer/installers` and use a custom type
56 | > that it handles.
57 |
--------------------------------------------------------------------------------
/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "Should I commit the dependencies in my vendor directory?"
4 | permalink: /doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md/
5 | ---
6 |
7 | # Should I commit the dependencies in my vendor directory?
8 |
9 | The general recommendation is **no**. The vendor directory (or wherever your
10 | dependencies are installed) should be added to `.gitignore`/`svn:ignore`/etc.
11 |
12 | The best practice is to then have all the developers use Composer to install
13 | the dependencies. Similarly, the build server, CI, deployment tools etc should
14 | be adapted to run Composer as part of their project bootstrapping.
15 |
16 | While it can be tempting to commit it in some environment, it leads to a few
17 | problems:
18 |
19 | - Large VCS repository size and diffs when you update code.
20 | - Duplication of the history of all your dependencies in your own VCS.
21 | - Adding dependencies installed via git to a git repo will show them as
22 | submodules. This is problematic because they are not real submodules, and you
23 | will run into issues.
24 |
25 | If you really feel like you must do this, you have a few options:
26 |
27 | 1. Limit yourself to installing tagged releases (no dev versions), so that you
28 | only get zipped installs, and avoid problems with the git "submodules".
29 | 2. Use --prefer-dist or set `preferred-install` to `dist` in your
30 | [config](../04-schema.md#config).
31 | 3. Remove the `.git` directory of every dependency after the installation, then
32 | you can add them to your git repo. You can do that with `rm -rf vendor/**/.git`
33 | in ZSH or `find vendor/ -type d -name ".git" -exec rm -rf {% raw %}{}{% endraw %} \;` in Bash.
34 | but this means you will have to delete those dependencies from disk before
35 | running composer update.
36 | 4. Add a .gitignore rule (`vendor/.git`) to ignore all the vendor `.git` folders.
37 | This approach does not require that you delete dependencies from disk prior to
38 | running a composer update.
39 |
--------------------------------------------------------------------------------
/doc/faqs/why-are-unbound-version-constraints-a-bad-idea.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "Why are unbound version constraints a bad idea?"
4 | permalink: /doc/faqs/why-are-unbound-version-constraints-a-bad-idea.md/
5 | ---
6 |
7 | # Why are unbound version constraints a bad idea?
8 |
9 | A version constraint without an upper bound such as `*`, `>=3.4` or
10 | `dev-master` will allow updates to any future version of the dependency.
11 | This includes major versions breaking backward compatibility.
12 |
13 | Once a release of your package is tagged, you cannot tweak its dependencies
14 | anymore in case a dependency breaks BC - you have to do a new release but the
15 | previous one stays broken.
16 |
17 | The only good alternative is to define an upper bound on your constraints,
18 | which you can increase in a new release after testing that your package is
19 | compatible with the new major version of your dependency.
20 |
21 | For example instead of using `>=3.4` you should use `~3.4` which allows all
22 | versions up to `3.999` but does not include `4.0` and above. The `~` operator
23 | works very well with libraries follow [semantic versioning](http://semver.org).
24 |
25 | **Note:** As a package maintainer, you can make the life of your users easier
26 | by providing an [alias version](../articles/aliases.md) for your development
27 | branch to allow it to match bound constraints.
28 |
--------------------------------------------------------------------------------
/doc/faqs/why-are-version-constraints-combining-comparisons-and-wildcards-a-bad-idea.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "Why are version constraints combining comparisons and wildcards a bad idea?"
4 | permalink: /doc/faqs/why-are-version-constraints-combining-comparisons-and-wildcards-a-bad-idea.md/
5 | ---
6 |
7 | # Why are version constraints combining comparisons and wildcards a bad idea?
8 |
9 | This is a fairly common mistake people make, defining version constraints in
10 | their package requires like `>=2.*` or `>=1.1.*`.
11 |
12 | If you think about it and what it really means though, you will quickly
13 | realize that it does not make much sense. If we decompose `>=2.*`, you
14 | have two parts:
15 |
16 | - `>=2` which says the package should be in version 2.0.0 or above.
17 | - `2.*` which says the package should be between version 2.0.0 (inclusive)
18 | and 3.0.0 (exclusive).
19 |
20 | As you see, both rules agree on the fact that the package must be >=2.0.0,
21 | but it is not possible to determine if when you wrote that you were thinking
22 | of a package in version 3.0.0 or not. Should it match because you asked for
23 | `>=2` or should it not match because you asked for a `2.*`?
24 |
25 | For this reason, Composer just throws an error and says that this is invalid.
26 | The easy way to fix it is to think about what you really mean, and use only
27 | one of those rules.
--------------------------------------------------------------------------------
/doc/faqs/why-can't-composer-load-repositories-recursively.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "Why can't Composer load repositories recursively?"
4 | permalink: /doc/faqs/why-can't-composer-load-repositories-recursively.md/
5 | ---
6 |
7 | # Why can't Composer load repositories recursively?
8 |
9 | You may run into problems when using custom repositories because Composer does
10 | not load the repositories of your requirements, so you have to redefine those
11 | repositories in all your `composer.json` files.
12 |
13 | Before going into details as to why this is like that, you have to understand
14 | that the main use of custom VCS & package repositories is to temporarily try
15 | some things, or use a fork of a project until your pull request is merged, etc.
16 | You should not use them to keep track of private packages. For that you should
17 | look into [setting up Satis](../articles/handling-private-packages-with-satis.md)
18 | or getting a [Toran Proxy](https://toranproxy.com) license for your company.
19 |
20 | There are three ways the dependency solver could work with custom repositories:
21 |
22 | - Fetch the repositories of root package, get all the packages from the defined
23 | repositories, resolve requirements. This is the current state and it works well
24 | except for the limitation of not loading repositories recursively.
25 |
26 | - Fetch the repositories of root package, while initializing packages from the
27 | defined repos, initialize recursively all repos found in those packages, and
28 | their package's packages, etc, then resolve requirements. It could work, but it
29 | slows down the initialization a lot since VCS repos can each take a few seconds,
30 | and it could end up in a completely broken state since many versions of a package
31 | could define the same packages inside a package repository, but with different
32 | dist/source. There are many many ways this could go wrong.
33 |
34 | - Fetch the repositories of root package, then fetch the repositories of the
35 | first level dependencies, then fetch the repositories of their dependencies, etc,
36 | then resolve requirements. This sounds more efficient, but it suffers from the
37 | same problems than the second solution, because loading the repositories of the
38 | dependencies is not as easy as it sounds. You need to load all the repos of all
39 | the potential matches for a requirement, which again might have conflicting
40 | package definitions.
41 |
--------------------------------------------------------------------------------
/doc/fixtures/fixtures.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | title: "`Composer` type repository fixtures"
4 | permalink: /doc/fixtures/fixtures.md/
5 | ---
6 |
7 | # `Composer` type repository fixtures
8 |
9 | This directory contains some examples of what `composer` type repositories can look like. They serve as illustrating examples accompanying the docs, but can also be used as (initial) fixtures for tests.
10 |
11 | * `repo-composer-plain` is a simple, plain `packages.json` file
12 | * `repo-composer-with-includes` uses the `includes` mechanism
13 | * `repo-composer-with-providers` uses the `providers` mechanism
14 |
15 | Sample Packages used in these fixtures
16 | -------
17 |
18 | All these repositories contain the following packages.
19 |
20 | * `foo/bar` versions 1.0.0, 1.0.1 and 1.1.0; dev-default and 1.0.x-dev branches. On dev-default and in 1.1.0, `bar/baz` ~1.0 is required.
21 | * `qux/quux` only has a dev-default branch. It `replace`s `gar/nix`.
22 | * `gar/nix` has a 1.0.0 version and a dev-default branch. It is being replaced by `qux/quux`.
23 | * `bar/baz` has a 1.0.0 version and 1.0.x-dev as well as dev-default branches. Additionally, 1.1.x-dev is a branch alias for dev-default.
24 |
25 |
26 |
--------------------------------------------------------------------------------
/feed.xml:
--------------------------------------------------------------------------------
1 | ---
2 | layout: null
3 | ---
4 |
5 |
6 |
7 | {{ site.title | xml_escape }}
8 | {{ site.description | xml_escape }}
9 | {{ site.url }}{{ site.baseurl }}/
10 |
11 | {{ site.time | date_to_rfc822 }}
12 | {{ site.time | date_to_rfc822 }}
13 | Jekyll v{{ jekyll.version }}
14 | {% for post in site.posts limit:10 %}
15 |
16 | {{ post.title | xml_escape }}
17 | {{ post.content | xml_escape }}
18 | {{ post.date | date_to_rfc822 }}
19 | {{ post.url | prepend: site.baseurl | prepend: site.url }}
20 | {{ post.url | prepend: site.baseurl | prepend: site.url }}
21 | {% for tag in post.tags %}
22 | {{ tag | xml_escape }}
23 | {% endfor %}
24 | {% for cat in post.categories %}
25 | {{ cat | xml_escape }}
26 | {% endfor %}
27 |
28 | {% endfor %}
29 |
30 |
31 |
--------------------------------------------------------------------------------
/images/NAVER_D2_Symbol.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/NAVER_D2_Symbol.png
--------------------------------------------------------------------------------
/images/NAVER_D2_c_hor.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/NAVER_D2_c_hor.png
--------------------------------------------------------------------------------
/images/XE_symbol.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/XE_symbol.png
--------------------------------------------------------------------------------
/images/XE_symbol_512.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/XE_symbol_512.png
--------------------------------------------------------------------------------
/images/bnr1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/bnr1.png
--------------------------------------------------------------------------------
/images/bnr2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/bnr2.png
--------------------------------------------------------------------------------
/images/bnr3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/bnr3.png
--------------------------------------------------------------------------------
/images/bnr4.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/bnr4.png
--------------------------------------------------------------------------------
/images/bnr5.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/bnr5.png
--------------------------------------------------------------------------------
/images/body-bg.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/body-bg.jpg
--------------------------------------------------------------------------------
/images/download-button.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/download-button.png
--------------------------------------------------------------------------------
/images/github-button.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/github-button.png
--------------------------------------------------------------------------------
/images/header-bg.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/header-bg.jpg
--------------------------------------------------------------------------------
/images/highlight-bg.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/highlight-bg.jpg
--------------------------------------------------------------------------------
/images/laravel-banner.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/laravel-banner.png
--------------------------------------------------------------------------------
/images/logo-composer-transparent.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/logo-composer-transparent.png
--------------------------------------------------------------------------------
/images/sidebar-bg.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/sidebar-bg.jpg
--------------------------------------------------------------------------------
/images/xeicon_banner.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/images/xeicon_banner.png
--------------------------------------------------------------------------------
/index.html:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | ---
4 |
5 |
43 |
--------------------------------------------------------------------------------
/js/prism.js:
--------------------------------------------------------------------------------
1 | /* http://prismjs.com/download.html?themes=prism&languages=markup+css+clike+javascript+php */
2 | self="undefined"!=typeof window?window:"undefined"!=typeof WorkerGlobalScope&&self instanceof WorkerGlobalScope?self:{};var Prism=function(){var e=/\blang(?:uage)?-(?!\*)(\w+)\b/i,t=self.Prism={util:{encode:function(e){return e instanceof n?new n(e.type,t.util.encode(e.content),e.alias):"Array"===t.util.type(e)?e.map(t.util.encode):e.replace(/&/g,"&").replace(/e.length)break e;if(!(d instanceof a)){u.lastIndex=0;var m=u.exec(d);if(m){c&&(f=m[1].length);var y=m.index-1+f,m=m[0].slice(f),v=m.length,k=y+v,b=d.slice(0,y+1),w=d.slice(k+1),N=[p,1];b&&N.push(b);var O=new a(l,g?t.tokenize(m,g):m,h);N.push(O),w&&N.push(w),Array.prototype.splice.apply(r,N)}}}}}return r},hooks:{all:{},add:function(e,n){var a=t.hooks.all;a[e]=a[e]||[],a[e].push(n)},run:function(e,n){var a=t.hooks.all[e];if(a&&a.length)for(var r,i=0;r=a[i++];)r(n)}}},n=t.Token=function(e,t,n){this.type=e,this.content=t,this.alias=n};if(n.stringify=function(e,a,r){if("string"==typeof e)return e;if("Array"===t.util.type(e))return e.map(function(t){return n.stringify(t,a,e)}).join("");var i={type:e.type,content:n.stringify(e.content,a,r),tag:"span",classes:["token",e.type],attributes:{},language:a,parent:r};if("comment"==i.type&&(i.attributes.spellcheck="true"),e.alias){var l="Array"===t.util.type(e.alias)?e.alias:[e.alias];Array.prototype.push.apply(i.classes,l)}t.hooks.run("wrap",i);var s="";for(var o in i.attributes)s+=o+'="'+(i.attributes[o]||"")+'"';return"<"+i.tag+' class="'+i.classes.join(" ")+'" '+s+">"+i.content+""},!self.document)return self.addEventListener?(self.addEventListener("message",function(e){var n=JSON.parse(e.data),a=n.language,r=n.code;self.postMessage(JSON.stringify(t.util.encode(t.tokenize(r,t.languages[a])))),self.close()},!1),self.Prism):self.Prism;var a=document.getElementsByTagName("script");return a=a[a.length-1],a&&(t.filename=a.src,document.addEventListener&&!a.hasAttribute("data-manual")&&document.addEventListener("DOMContentLoaded",t.highlightAll)),self.Prism}();"undefined"!=typeof module&&module.exports&&(module.exports=Prism);;
3 | Prism.languages.markup={comment://,prolog:/<\?.+?\?>/,doctype://,cdata://i,tag:{pattern:/<\/?[\w:-]+\s*(?:\s+[\w:-]+(?:=(?:("|')(\\?[\w\W])*?\1|[^\s'">=]+))?\s*)*\/?>/i,inside:{tag:{pattern:/^<\/?[\w:-]+/i,inside:{punctuation:/^<\/?/,namespace:/^[\w-]+?:/}},"attr-value":{pattern:/=(?:('|")[\w\W]*?(\1)|[^\s>]+)/i,inside:{punctuation:/=|>|"/}},punctuation:/\/?>/,"attr-name":{pattern:/[\w:-]+/,inside:{namespace:/^[\w-]+?:/}}}},entity:/&#?[\da-z]{1,8};/i},Prism.hooks.add("wrap",function(t){"entity"===t.type&&(t.attributes.title=t.content.replace(/&/,"&"))});;
4 | Prism.languages.css={comment:/\/\*[\w\W]*?\*\//,atrule:{pattern:/@[\w-]+?.*?(;|(?=\s*\{))/i,inside:{punctuation:/[;:]/}},url:/url\((?:(["'])(\\\n|\\?.)*?\1|.*?)\)/i,selector:/[^\{\}\s][^\{\};]*(?=\s*\{)/,string:/("|')(\\\n|\\?.)*?\1/,property:/(\b|\B)[\w-]+(?=\s*:)/i,important:/\B!important\b/i,punctuation:/[\{\};:]/,"function":/[-a-z0-9]+(?=\()/i},Prism.languages.markup&&(Prism.languages.insertBefore("markup","tag",{style:{pattern:/[\w\W]*?<\/style>/i,inside:{tag:{pattern:/|<\/style>/i,inside:Prism.languages.markup.tag.inside},rest:Prism.languages.css},alias:"language-css"}}),Prism.languages.insertBefore("inside","attr-value",{"style-attr":{pattern:/\s*style=("|').*?\1/i,inside:{"attr-name":{pattern:/^\s*style/i,inside:Prism.languages.markup.tag.inside},punctuation:/^\s*=\s*['"]|['"]\s*$/,"attr-value":{pattern:/.+/i,inside:Prism.languages.css}},alias:"language-css"}},Prism.languages.markup.tag));;
5 | Prism.languages.clike={comment:[{pattern:/(^|[^\\])\/\*[\w\W]*?\*\//,lookbehind:!0},{pattern:/(^|[^\\:])\/\/.*/,lookbehind:!0}],string:/("|')(\\\n|\\?.)*?\1/,"class-name":{pattern:/((?:(?:class|interface|extends|implements|trait|instanceof|new)\s+)|(?:catch\s+\())[a-z0-9_\.\\]+/i,lookbehind:!0,inside:{punctuation:/(\.|\\)/}},keyword:/\b(if|else|while|do|for|return|in|instanceof|function|new|try|throw|catch|finally|null|break|continue)\b/,"boolean":/\b(true|false)\b/,"function":{pattern:/[a-z0-9_]+\(/i,inside:{punctuation:/\(/}},number:/\b-?(0x[\dA-Fa-f]+|\d*\.?\d+([Ee]-?\d+)?)\b/,operator:/[-+]{1,2}|!|<=?|>=?|={1,3}|&{1,2}|\|?\||\?|\*|\/|~|\^|%/,ignore:/&(lt|gt|amp);/i,punctuation:/[{}[\];(),.:]/};;
6 | Prism.languages.javascript=Prism.languages.extend("clike",{keyword:/\b(break|case|catch|class|const|continue|debugger|default|delete|do|else|enum|export|extends|false|finally|for|function|get|if|implements|import|in|instanceof|interface|let|new|null|package|private|protected|public|return|set|static|super|switch|this|throw|true|try|typeof|var|void|while|with|yield)\b/,number:/\b-?(0x[\dA-Fa-f]+|\d*\.?\d+([Ee][+-]?\d+)?|NaN|-?Infinity)\b/,"function":/(?!\d)[a-z0-9_$]+(?=\()/i}),Prism.languages.insertBefore("javascript","keyword",{regex:{pattern:/(^|[^/])\/(?!\/)(\[.+?]|\\.|[^/\r\n])+\/[gim]{0,3}(?=\s*($|[\r\n,.;})]))/,lookbehind:!0}}),Prism.languages.markup&&Prism.languages.insertBefore("markup","tag",{script:{pattern:/[\w\W]*?<\/script>/i,inside:{tag:{pattern:/|<\/script>/i,inside:Prism.languages.markup.tag.inside},rest:Prism.languages.javascript},alias:"language-javascript"}});;
7 | Prism.languages.php=Prism.languages.extend("clike",{keyword:/\b(and|or|xor|array|as|break|case|cfunction|class|const|continue|declare|default|die|do|else|elseif|enddeclare|endfor|endforeach|endif|endswitch|endwhile|extends|for|foreach|function|include|include_once|global|if|new|return|static|switch|use|require|require_once|var|while|abstract|interface|public|implements|private|protected|parent|throw|null|echo|print|trait|namespace|final|yield|goto|instanceof|finally|try|catch)\b/i,constant:/\b[A-Z0-9_]{2,}\b/,comment:{pattern:/(^|[^\\])(\/\*[\w\W]*?\*\/|(^|[^:])(\/\/).*?(\r?\n|$))/,lookbehind:!0}}),Prism.languages.insertBefore("php","class-name",{"shell-comment":{pattern:/(^|[^\\])#.*?(\r?\n|$)/,lookbehind:!0,alias:"comment"}}),Prism.languages.insertBefore("php","keyword",{delimiter:/(\?>|<\?php|<\?)/i,variable:/(\$\w+)\b/i,"package":{pattern:/(\\|namespace\s+|use\s+)[\w\\]+/,lookbehind:!0,inside:{punctuation:/\\/}}}),Prism.languages.insertBefore("php","operator",{property:{pattern:/(->)[\w]+/,lookbehind:!0}}),Prism.languages.markup&&(Prism.hooks.add("before-highlight",function(e){"php"===e.language&&(e.tokenStack=[],e.backupCode=e.code,e.code=e.code.replace(/(?:<\?php|<\?)[\w\W]*?(?:\?>)/gi,function(n){return e.tokenStack.push(n),"{{{PHP"+e.tokenStack.length+"}}}"}))}),Prism.hooks.add("before-insert",function(e){"php"===e.language&&(e.code=e.backupCode,delete e.backupCode)}),Prism.hooks.add("after-highlight",function(e){if("php"===e.language){for(var n,a=0;n=e.tokenStack[a];a++)e.highlightedCode=e.highlightedCode.replace("{{{PHP"+(a+1)+"}}}",Prism.highlight(n,e.grammar,"php"));e.element.innerHTML=e.highlightedCode}}),Prism.hooks.add("wrap",function(e){"php"===e.language&&"markup"===e.type&&(e.content=e.content.replace(/(\{\{\{PHP[0-9]+\}\}\})/g,'$1'))}),Prism.languages.insertBefore("php","comment",{markup:{pattern:/<[^?]\/?(.*?)>/,inside:Prism.languages.markup},php:/\{\{\{PHP[0-9]+\}\}\}/}));;
8 |
--------------------------------------------------------------------------------
/webfonts/LICENSE:
--------------------------------------------------------------------------------
1 | 네이버 나눔글꼴의 지적 재산권은 네이버와 네이버문화재단에 있습니다.
2 | 네이버 나눔글꼴은 개인 및 기업 사용자를 포함한 모든 사용자에게
3 | 무료로 제공되며 자유롭게 수정하고 재배포하실 수 있습니다.
4 |
5 | 단, 글꼴 자체를 유료로 판매하는 것은 금지하며
6 | 네이버 나눔글꼴은 본 저작권 안내와 라이선스 전문을 포함해서
7 | 다른 소프트웨어와 번들하거나 재배포 또는 판매가 가능합니다.
8 |
9 | 네이버 나눔글꼴 라이선스 전문을 포함하기 어려울 경우,
10 | 나눔글꼴의 출처 표기를 권장합니다.
11 |
12 | 예) 이 페이지에는 네이버에서 제공한 나눔글꼴이 적용되어 있습니다.
13 |
14 | 네이버 나눔글꼴을 사용한 인쇄물, 광고물(온라인 포함)의 이미지는
15 | 나눔글꼴 프로모션을 위해 활용될 수 있습니다.
16 |
17 | 이를 원치 않는 사용자는 언제든지 당사에 요청하실 수 있습니다.
18 | 정확한 사용 조건은 아래 네이버 나눔글꼴 라이선스 전문을 참고하시기 바랍니다
19 |
20 | *나눔글꼴 라이선스 전문의 한글은 이용자의 이해를 돕기 위해 영문 원본을 번역해 서비스하고 있으며
21 | 법적 효력은 영문에 한합니다. 이 점 참고하시기 바랍니다.
22 |
23 | Copyright (c) 2010, NAVER Corporation (http://www.nhncorp.com),
24 |
25 | with Reserved Font Name Nanum, Naver Nanum, NanumGothic, Naver NanumGothic, NanumMyeongjo, Naver NanumMyeongjo, NanumBrush, Naver NanumBrush, NanumPen, Naver NanumPen, Naver NanumGothicEco, NanumGothicEco, Naver NanumMyeongjoEco, NanumMyeongjoEco, Naver NanumGothicLight, NanumGothicLight, NanumBarunGothic, Naver NanumBarunGothic,
26 | This Font Software is licensed under the SIL Open Font License, Version 1.1.
27 | This license is copied below, and is also available with a FAQ at: http://scripts.sil.org/OFL
28 | SIL OPEN FONT LICENSE
29 | Version 1.1 - 26 February 2007
30 |
31 | ‘나눔, 네이버 나눔, 나눔고딕, 네이버 나눔고딕, 나눔명조, 네이버 나눔명조, 나눔손글씨, 네이버 나눔손글씨, 나눔펜, 네이버 나눔펜, 네이버 나눔고딕에코, 나눔고딕에코, 네이버 나눔명조에코, 나눔명조에코, 네이버 나눔고딕라이트, 나눔고딕라이트, 나눔바른고딕, 네이버나눔바른고딕’ 폰트명에 대해 NAVER (http://www.nhncorp.com)이 저작권을 소유하고 있습니다.
32 | 본 폰트 소프트웨어는 SIL 오픈 폰트 라이선스 버전 1.1에 따라 라이선스 취득을 하였습니다.
33 | 본 라이선스는 하단에 복사되었고 http://scripts.sil.org/OFL의 FAQ란 에서도 열람가능 합니다.
34 |
35 | SIL 오픈 폰트 라이선스
36 | 버전 1.1 (2007년 2월 26일)
37 |
38 | DEFINITIONS
39 | "Font Software" refers to the set of files released by the Copyright Holder(s) under this license and clearly marked as such. This may include source files, build scripts and documentation.
40 |
41 | "Reserved Font Name" refers to any names specified as such after the copyright statement(s).
42 | "Original Version" refers to the collection of Font Software components as distributed by the Copyright Holder(s).
43 |
44 | "Modified Version" refers to any derivative made by adding to, deleting, or substituting in part or in whole any of the components of the Original Version, by changing formats or by porting the Font Software to a new environment.‘
45 |
46 | "Author" refers to any designer, engineer, programmer, technical writer or other person who contributed to the Font Software.
47 |
48 | 정의
49 | ‘폰트 소프트웨어’는 본 라이선스에 입거해 저작권자가 배포하고 명확하게 같은 표시가 된 파일들의 집합을 뜻하며, 여기에는 소스 파일, 빌드 스크립트와 문서가 이에 포함됩니다.
50 | ‘저작권이 있는 폰트명’은 저작권 정책에 따라서 지정된 이름을 말합니다.
51 | ‘원본’은 저작권자가 배포한 폰트 소프트웨어 구성요소를 의미합니다.
52 | ‘수정본’은 포맷의 변경이나 폰트 소프트웨어를 새로운 환경에 포팅시켜, 원본의 일부 혹은 전체에 추가, 삭제 대체해 만든 파생 저작물을 의미합니다.
53 | ‘저자’는 폰트 소프트웨어에 기여한 디자이너, 엔지니어, 프로그래머, 기술 전문가 등을 의미합니다.
54 |
55 | PREAMBLE
56 | The goals of the Open Font License (OFL) are to stimulate worldwide development of collaborative font projects,
57 | to support the font creation efforts of academic and linguistic communities, and to provide a free and open framework in which fonts may be shared and improved in partnership with others.
58 | The OFL allows the licensed fonts to be used, studied, modified and redistributed freely as long as they are not sold
59 | by themselves. The fonts, including any derivative works, can be bundled, embedded, redistributed and/or sold with any software provided that any reserved names are not used by derivative works.
60 | The fonts and derivatives, however, cannot be released under any other type of license.
61 | The requirement for fonts to remain under this license does not apply to any document created using the fonts or their derivatives.
62 |
63 | 전문
64 | 본 폰트 라이선스를 오픈 하는 것은(이하 OFL)는 전 세계 폰트 개발 프로젝트를 지원하고 학계와 언어 관련 학계의 폰트 개발을 위한 연구를 지지하기 위해서인 동시에, 폰트 제휴를 통해 폰트가 공유되고 개선될 수 있는 자유롭게 개방된 환경을 만들기 위해서 입니다.
65 |
66 | OFL은 라이선스를 취득한 폰트가 그 자체로 판매되지 않는 한 자유롭게 사용, 연구, 수정, 재배포 하는 것을 허가합니다. 수정된 폰트를 포함한 폰트는 저작권 명이 사용되지 않는 한 기타 소프트웨어와 함께 묶이거나 삽입, 재배포 할 수 있습니다. 단 폰트와 수정된 폰트는 기타 다른 라이선스에 포함되어 배포될 수는 없습니다. 이 라이선스 하에 있기 위한 폰트에 대한 요구사항은 본 폰트나 수정본을 사용하여 제작된 어떠한 문서에도 적용되지 않습니다.
67 |
68 | PERMISSION & CONDITIONS
69 | Permission is hereby granted, free of charge, to any person obtaining a copy of the Font Software, to use, study, copy, merge, embed, modify, redistribute, and sell modified and unmodified copies of the Font Software, subject to the following conditions:
70 |
71 | 허가 및 조건
72 | 본 폰트 소프트웨어를 사용하도록 허가 받은 개인/기업/단체 누구라도 다음 명시된 조건에 따라 폰트 소프트웨어의 수정 혹은 수정되지 않은 복사본을 무료로 사용, 연구, 복사, 통합, 삽입, 수정, 재배포할 수 있도록 허가합니다.
73 |
74 | 1) Neither the Font Software nor any of its individual components,in Original or Modified Versions, may be sold by itself.
75 | 원본이나 수정본의 폰트 소프트웨어 혹은 개별 구성요소인 폰트 자체가 판매되어서는 안됩니다.
76 |
77 | 2) Original or Modified Versions of the Font Software may be bundled, redistributed and/or sold with any software, provided that each copy contains the above copyright notice and this license. These can be included either as stand-alone text files, human-readable headers or in the appropriate machine-readable metadata fields within text or binary files as long as those fields can be easily viewed by the user.
78 |
79 | 본 폰트 소프트웨어의 원본 혹은 수정본은 상기 저작권 안내와 본 라이선스에 대한 내용을 포함하는 경우에는 다른 소프트웨어와 함께 묶이거나 재배포 혹은 판매가 가능합니다. 이는 독립 텍스트 파일과 가독성이 있는 헤더 혹은 유저가 용이하게 열람 가능한 이상 텍스트파일 혹은 이진파일 내 기계가 읽을 수 있는 메타데이터 형태를 모두 의미 합니다.
80 |
81 | 3) No Modified Version of the Font Software may use the Reserved Font Name(s) unless explicit written
82 | permission is granted by the corresponding Copyright Holder. This restriction only applies to the primary font name as presented to the users.
83 |
84 | 본 폰트 소프트웨어의 어떠한 수정본도 동일한 저작권자가 명시적 허가서를 부여하지 않는 한 저작권이 있는 폰트명을 사용해서는 안 됩니다. 본 제한 사항은 유저들에게 제공된 기존 폰트명을 뜻합니다.
85 |
86 | 4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font Software shall not be used to promote, endorse or advertise any Modified Version, except to acknowledge the contribution(s) of the Copyright Holder(s) and the Author(s) or with their explicit written permission.
87 |
88 | 본 폰트 소프트웨어의 저작권자 혹은 저자의 이름은 그들의 명시적 서면 허가가 있거나 또는 그들의 공헌을 인정하기 위한 경우를 제외하고는 수정본에 대한 사용을 유도,추천 혹은 광고하기 위한 목적으로 사용할 수 없습니다.
89 |
90 | 5) The Font Software, modified or unmodified, in part or in whole, must be distributed entirely under this license, and must not be distributed any other license. The requirement for fonts to remain under this license does not apply to any document created using the Font Software.
91 |
92 | 본 폰트 소프트웨어는 전체나 부분, 혹은 수정 여부에 상관없이 본 라이선스 하에 배포가 되어야 하며 기타 다른 라이선스 하에서는 배포를 할 수 없습니다. 폰트에 대한 요구조건은 이 라이선스 하에서만 유효하며 이 라이선스 하에 있기 위한 폰트에 대한 요구사항은 본 폰트 소프트웨어를 사용해 제작한 어떠한 문서에도 적용되지 않습니다.
93 |
94 | TERMINATION 계약의 종료
95 | This license becomes null and void if any of the above conditions are not met.
96 | 본 라이선스는 상기 조건 중 일부라도 부합되지 않으면 무효가 될 수 있습니다.
97 |
98 | DISCLAIMER
99 | THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE.
100 |
101 | 면책조항
102 | 본 폰트 소프트웨어는 저작권, 특허권, 상표권 및 기타 권리의 비침해성과 특정 목적에의 적합성 포함한 명시적, 묵시적인 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 어떠한 경우에도 저작권자는 본 폰트 소프트웨어의 사용 또는 이의 사용불가, 그밖에 폰트 소프트웨어의 취급과 관련하여 발생하는 모든 계약, 불법행위 혹은 다른 일로 하여금 발생하는 일반적, 특수적, 간접적, 부차적 혹은 필연적 손해를 포함하는 소송, 손해, 혹은 기타 책임에 대한 의무를 가지지 않습니다.
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothic.eot:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothic.eot
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothic.ttf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothic.ttf
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothic.woff:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothic.woff
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothic.woff2:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothic.woff2
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothicBold.eot:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothicBold.eot
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothicBold.ttf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothicBold.ttf
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothicBold.woff:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothicBold.woff
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothicBold.woff2:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothicBold.woff2
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothicLight.eot:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothicLight.eot
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothicLight.ttf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothicLight.ttf
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothicLight.woff:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothicLight.woff
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothicLight.woff2:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothicLight.woff2
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothicUltraLight.eot:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothicUltraLight.eot
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothicUltraLight.ttf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothicUltraLight.ttf
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothicUltraLight.woff:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothicUltraLight.woff
--------------------------------------------------------------------------------
/webfonts/NanumBarunGothicUltraLight.woff2:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/xpressengine/Composer-korean-docs/6631b9911a81f93aff41f02e7d501759d4ca9458/webfonts/NanumBarunGothicUltraLight.woff2
--------------------------------------------------------------------------------
/webfonts/README.md:
--------------------------------------------------------------------------------
1 | # Nanum Barun Gothic Web Fonts
2 |
3 | Web Font Version of Nanum Barun Gothic. Created by [NAVER](http://www.naver.com) in Oct, 2013.
4 |
5 | ## Weights
6 |
7 | - Bold(700)
8 | - Regular(400)
9 | - Light(300)
10 | - UltraLight(200)
11 |
12 | ##Formats
13 |
14 | - ttf
15 | - eot
16 | - woff
17 | - woff2
18 |
19 | ## Installation
20 |
21 | **Install via Bower**
22 |
23 | ```
24 | bower install NanumBarunGothic
25 | ```
26 |
27 | ## Applying
28 |
29 | **CSS**
30 |
31 | Insert `nanumbarungothic.css` to your HTML.
32 |
33 | ```html
34 |
35 | ```
36 |
37 | Use your own way!
38 |
39 | ```css
40 | body {
41 | font-family: 'Nanum Barun Gothic', sans-serif;
42 | }
43 | ```
44 |
45 | ## Demo
46 |
47 | [Demo Page](http://hiun.github.io/NanumBarunGothic)
48 |
49 | ## Contributors
50 |
51 | [wan2land](https://github.com/wan2land) - Providing converted new Light and UltraLight font, providing WOFF2 format for all font family.
52 |
53 | [EzKorry](https://github.com/EzKorry) - Issuing about `Content-Type` error in demo code.
54 |
55 | [kaiserjun](https://github.com/kaiserjun) - Issuing about conversion error in `.woff` format font.
56 |
57 | ##License
58 |
59 | Copyright (c) 2010, NAVER Corporation (http://www.nhncorp.com)
--------------------------------------------------------------------------------
/webfonts/bower.json:
--------------------------------------------------------------------------------
1 | {
2 | "name": "NanumBarunGothic",
3 | "version": "1.0.0",
4 | "homepage": "https://github.com/hiun/NanumBarunGothic",
5 | "authors": [
6 | "Naver"
7 | ],
8 | "main": "nanumbarungothic.css",
9 | "keywords": [
10 | "nanum",
11 | "nanumbarungothic",
12 | "nanumgothic"
13 | ],
14 | "license": "SIL OPEN FONT LICENSE",
15 | "ignore": [
16 | "**/.*",
17 | "node_modules",
18 | "bower_components",
19 | "test",
20 | "tests"
21 | ]
22 | }
23 |
--------------------------------------------------------------------------------
/webfonts/example.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 | Example
5 |
6 |
7 |
8 |
9 |
23 |
24 |
25 |
26 |
27 | 나눔바른고딕 Font Weight : 200
28 | 나눔바른고딕 Font Weight : 300
29 | 나눔바른고딕 Font Weight : 400
30 | 나눔바른고딕 Font Weight : 700
31 |
32 |
33 |
34 |
--------------------------------------------------------------------------------
/webfonts/nanumbarungothic.css:
--------------------------------------------------------------------------------
1 | /*
2 | * Nanum Barun Gothic (Korean) http://hangeul.naver.com
3 | */
4 | @font-face {
5 | font-family: 'Nanum Barun Gothic';
6 | font-style: normal;
7 | font-weight: 200;
8 | src: url(./NanumBarunGothicUltraLight.eot);
9 | src: local('Nanum Barun Gothic UltraLight'),
10 | local('NanumBarunGothicUltraLight'),
11 | url(./NanumBarunGothicUltraLight.eot?#iefix) format('embedded-opentype'),
12 | url(./NanumBarunGothicUltraLight.woff2) format('woff2'),
13 | url(./NanumBarunGothicUltraLight.woff) format('woff'),
14 | url(./NanumBarunGothicUltraLight.ttf) format('truetype');
15 | }
16 |
17 | @font-face {
18 | font-family: 'Nanum Barun Gothic';
19 | font-style: normal;
20 | font-weight: 300;
21 | src: url(./NanumBarunGothicLight.eot);
22 | src: local('Nanum Barun Gothic Light'),
23 | local('NanumBarunGothicLight'),
24 | url(./NanumBarunGothicLight.eot?#iefix) format('embedded-opentype'),
25 | url(./NanumBarunGothicLight.woff2) format('woff2'),
26 | url(./NanumBarunGothicLight.woff) format('woff'),
27 | url(./NanumBarunGothicLight.ttf) format('truetype');
28 | }
29 |
30 | @font-face {
31 | font-family: 'Nanum Barun Gothic';
32 | font-style: normal;
33 | font-weight: 400;
34 | src: url(./NanumBarunGothic.eot);
35 | src: local('Nanum Barun Gothic'),
36 | local('NanumBarunGothic'),
37 | url(./NanumBarunGothic.eot?#iefix) format('embedded-opentype'),
38 | url(./NanumBarunGothic.woff2) format('woff2'),
39 | url(./NanumBarunGothic.woff) format('woff'),
40 | url(./NanumBarunGothic.ttf) format('truetype');
41 | }
42 |
43 | @font-face {
44 | font-family: 'Nanum Barun Gothic';
45 | font-style: normal;
46 | font-weight: 700;
47 | src: url(./NanumBarunGothicBold.eot);
48 | src: local('Nanum Barun Gothic Bold'),
49 | local('NanumBarunGothicBold'),
50 | url(./NanumBarunGothicBold.eot?#iefix) format('embedded-opentype'),
51 | url(./NanumBarunGothicBold.woff2) format('woff2'),
52 | url(./NanumBarunGothicBold.woff) format('woff'),
53 | url(./NanumBarunGothicBold.ttf) format('truetype');
54 | }
55 |
56 |
--------------------------------------------------------------------------------
5 | 
