09s-creating-a-meteorite-package.md.erb

---
title: Publikacja pakietu na meteorite
slug: creating-a-meteorite-package
date: 0009/01/02
number: 9.5
sidebar: true
contents: Jak stworzyć lokalny pakiet.|Jak pisać testy dla twojego pakietu.|Jak opublikować pakiet na Atmosphere.
paragraphs: 22
---

Napisaliśmy kod obsługi błędów umożliwiając jego wielokrotne wykorzystanie. Dlaczego więc nie spakować go i nie stworzyć z niego inteligentnego pakietu i nie podzielić się z nim z resztą społeczności Meteor'a?

Najpierw musimy stworzyć strukturę plików dla naszego pakietu, w którym będzie rezydować. Umieszczamy nasz pakiet w katalogu `packages/errors/`. Tworzy to niestandardowy pakiet, który jest automatycznie przygotowany do użycia. (Mogłeś zauważyć, że Meteorite instaluje pakiety poprzez tworzenie linków symbolicznych w katalogu `packages/`).

Następnie tworzymy w tym katalogu plik `package.js`. Plik ten informuje Meteor'a o tym jak pakiet powinien być używany oraz dostarcza informacji o zmiennych, które eksportuje.

~~~js
Package.describe({
  summary: "Szablon do wyświetlania użytkownikowi błędów aplikacji."
});

Package.on_use(function (api, where) {
  api.use(['minimongo', 'mongo-livedata', 'templating'], 'client');

  api.add_files(['errors.js', 'errors_list.html', 'errors_list.js'], 'client');
  
  if (api.export) 
    api.export('Errors');
});
~~~
<%= caption "packages/errors/package.js" %>

Dodajmy trzy pliki do nowego pakietu. Możemy je skopiować z Microscope bez większych zmian z wyjątkiem konieczności zmiany przestrzeni nazw i bardziej uporządkowanego API:  

~~~js
Errors = {
  // Kolekcja lokalna (tylko po stronie klienta)
  collection: new Meteor.Collection(null),
  
  throw: function(message) {
    Errors.collection.insert({message: message, seen: false})
  },
  clearSeen: function() {
    Errors.collection.remove({seen: true});
  }
};

~~~
<%= caption "packages/errors/errors.js" %>

~~~html
<template name="meteorErrors">
  {{#each errors}}
    {{> meteorError}}
  {{/each}}
</template>

<template name="meteorError">
  <div class="alert alert-error">
    <button type="button" class="close" data-dismiss="alert">&times;</button>
    {{message}}
  </div>
</template>
~~~
<%= caption "packages/errors/errors_list.html" %>

~~~js
Template.meteorErrors.helpers({
  errors: function() {
    return Errors.collection.find();
  }
});

Template.meteorError.rendered = function() {
  var error = this.data;
  Meteor.defer(function() {
    Errors.collection.update(error._id, {$set: {seen: true}});
  });
};
~~~
<%= caption "packages/errors/errors_list.js" %>

### Testowanie pakietu z Microscope

Będziemy teraz testowali pakiet lokalnie z Microscope aby upewnić się, że zmiany w kodzie działają prawidłowo. Aby zlinkować pakiet z projektem, wykonujemy polecenie `meteor add errors`. Następnie musimy usunąć istniejące pliki, które zostały zastąpione przez nowy pakiet:

~~~bash
$ rm client/helpers/errors.js
$ rm client/views/includes/errors.html
$ rm client/views/includes/errors.js
~~~
<%= caption "usuwanie starych plików z konsoli" %>

Kolejną rzeczą, którą należy zrobić, są małe zmiany konieczne do użycia prawidłowego API:

~~~js
Router.before(function() { Errors.clearSeen(); });
~~~
<%= caption "lib/router.js" %>

~~~html
  {{> header}}
  {{> meteorErrors}}
~~~
<%= caption "client/views/application/layout.html" %>

~~~js
Meteor.call('post', post, function(error, id) {
  if (error) {
    // wyświetl błąd użytkownikowi
    Errors.throw(error.reason);

~~~
<%= caption "client/views/posts/post_submit.js" %>

~~~js
Posts.update(currentPostId, {$set: postProperties}, function(error) {
  if (error) {
    // wyświetl błąd użytkownikowi
    Errors.throw(error.reason);
~~~
<%= caption "client/views/posts/post_edit.js" %>

<%= scommit "9-5-1", "Utworzona podstawowa wersja pakietu i zlinkowanie go z aplikacją." %>

Po zastosowaniu powyższych zmian, powinniśmy zaobserwować aplikację działającą w ten sam sposób, co przed wprowadzeniem pakietu.

### Pisanie testów

Pierwszym krokiem podczas tworzenia pakietu jest testowanie go z aplikacją, a kolejnym jest napisanie zbioru testów, które odpowiednio testują sposób działania pakietu. Meteor pracuje z Tinytest (wbudowanym testerem pakietów), który ułatwia uruchamianie testów i zapewnia spokojny sen po udostępnieniu pakietu innym użytkownikom.

Stwórzmy plik z testami, który będzie używany przez Tinytest z kolekcją przechowującą błędy:

~~~js
Tinytest.add("Kolecja Errors funkcjonuje poprawnie.", function(test) {
  test.equal(Errors.collection.find({}).count(), 0);
  
  Errors.throw('Nowy błąd!');
  test.equal(Errors.collection.find({}).count(), 1);
  
  Errors.collection.remove({});
});

Tinytest.addAsync("Errors template works", function(test, done) {  
  Errors.throw('A new error!');
  test.equal(Errors.collection.find({seen: false}).count(), 1);
  
  // renderowanie szablonu
  OnscreenDiv(Spark.render(function() {
    return Template.meteorErrors();
  }));
  
  // poczekaj kilka milisekund
  Meteor.setTimeout(function() {
    test.equal(Errors.collection.find({seen: false}).count(), 0);
    test.equal(Errors.collection.find({}).count(), 1);
    Errors.clearSeen();
    
    test.equal(Errors.collection.find({seen: true}).count(), 0);
    done();
  }, 500);
});
~~~
<%= caption "packages/errors/errors_tests.js" %>

W powyższych testach sprawdzamy, że podstawowe funkcje `Meteor.Errors` działają poprawnie i upewniamy się, że kod `rendered` w szablonie nadal działa.

Nie opiszemy tu w pełni dokładnie jak pisać testy pakietów Meteora (ponieważ API nie jest jeszcze finalne i często ulega zmianom), ale mamy nadzieję, że kod jest zrozumiały.

Aby uruchomić testy w `pacakge.js`, użyj poniższy kod:

~~~js
Package.on_test(function(api) {
  api.use('errors', 'client');
  api.use(['tinytest', 'test-helpers'], 'client');  
  
  api.add_files('errors_tests.js', 'client');
});
~~~
<%= caption "packages/errors/package.js" %>

<%= scommit "9-5-2", "Dodanie testów do pakietu." %>

Nstępnie można uruchomić testy za pomocą:

~~~bash
$ meteor test-packages errors
~~~
<%= caption "Terminal" %>

<%= screenshot "s7-1", "Wszystkie testy przechodzą poprawnie." %>

### Publikacja pakietu

Teraz chcemy opublikować pakiet dla wszystkich użytkowników Meteora. Osiągniemy to przez opublikowanie go w Atmoshpere.

Po pierwsze, musimy dodać plik `smart.json`, aby przekazać ważne szczegóły dotyczące pakietu dla Meteora i Atmosphere:

~~~json
{
  "name": "errors",
  "description": "Szablon do wyświetlania błędów aplikacji uźytkownikowi.",
  "homepage": "https://github.com/tmeasday/meteor-errors",
  "author": "Tom Coleman <tom@thesnail.org>",
  "version": "0.1.0",
  "git": "https://github.com/tmeasday/meteor-errors.git",
  "packages": {
  }
}
~~~
<%= caption "packages/errors/smart.json" %>

<%= scommit "9-5-3", "Dodanie pliku smart.json" %>

Wstawiliśmy powyżej podstawowe metadane, które informują o pakiecie, opisują co robi, jego lokalizację git i początkowy numer wersji. Jeżeli nasz pakiet polegał na innych pakietach dostępnych w Atmosphere, możemy dodać sekcję `"packages"` aby opisać zależności.

Gdy wszystko to zostało dodane, publikacja pakietu jest łatwa. Musimy utworzyć repozytorium Git, następnie za pomocą git push opublikować kod na zdalnym serwerze i dodać link do niego w `smart.json`.

Proces, który należy wykonać na [GitHub](http://github.com), to utworzenie nowego repozytorium, a następnie podążanie za standardowymi krokami pozwalającymi umieścić kod pakietu w danym repozytorium. Następnie należy użyć polecenie `mrt release` aby go opublikować:

~~~bash
$ git init
$ git add -A
$ git commit -m "Utworzony Pakiet Errors"
$ git remote add origin https://github.com/tmeasday/meteor-errors.git
$ git push origin master
$ mrt release .
Zrobione!
~~~
<%= caption "Terminal (run from within `packages/errors`)" %>

Uwaga: nazwy pakietów muszą być unikatowe. Jeżeli utworzysz nazwę pakietu, który już istnieje nastąpi konflikt. W przyszłości Atmosphere będzie miało własną przestrzeń nazw dla każdego użytkownika, zatem weź po uwagę, że może się to zmienić.

Kolejna uwaga: Musisz się zalogować do http://atmosphere.meteor.com/accounts i stworzyć nowego użytkownika z hasłem, które będziesz wpisywał po wydaniu polecenia `mrt release`.

Teraz skoro pakiet został opublikowany, możemy usunąć go z projektu i dodać go bezpośrednio za pomocą Meteorite:

~~~bash
$ rm -r packages/errors
$ mrt add errors
~~~
<%= caption "Terminal (run from the top level of the app)" %>

<%= scommit "9-5-4", "Usunięto pakiet z aplikacji." %>

Powinieneś zobaczyć teraz w konsoli pierwsze pobieranie pakietu. Dobra robota!