Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • documentation/doc
  • PhilH/doc
  • louis.csn/doc
  • fabien4vo/doc
  • rngadam/doc
  • anastasia/doc
6 results
Show changes
Hide whitespace changes
Inline Side-by-side
Showing
with 233 additions and 491 deletions
source/import_documentation/Components/Solid-Widget.rst
View file @ 405339e9
......@@ -29,7 +29,58 @@ In a ``solid-widget``, you have access to these values:
- ``label``: if defined, label of the current field
- ``range``: if defined, range of the current field
..
.. note::
NB: Do not forget to define your custom template in a ``<template>``
tag. Otherwise, your widget will not be declared properly.
Attributes
----------
``data-holder``
~~~~~~~~~~~~~~~
Special attribute which can be inserted in a ``<solid-form>`` or an ``<input>`` within a ``<solid-widget>``.
When set on an element in the widget, it takes the ``value`` of this element and associate it with the ``field`` targetted by the widget.
If this attribute is combined with ``data-src="${value}"`` on a ``<solid-form>`` in a widget, values from the nested resource are directly editable. It works only if ``value`` is a resource (and not if it's a literal).
``data-src="${value}"``
~~~~~~~~~~~~~~~~~~~~~~~
It is usable to edit a nested resource (ie: a profile of a user, a customer of a project, ...) by creating a ``<solid-form>`` in a ``<solid-widget>``.
The ``value`` will be the ``@id`` of the nested resource, thus putting it in the ``data-src`` will create a form field on this nested resource.
It cannot be used without ``data-holder`` attribute.
The example below illustrates the input widget with and without ``value="${value}"``
(input's ``value="${value}"`` is equivalent to solid-form's ``data-src="${value}"``) :
.. code:: html
<solid-form
data-src="../data/list/users.jsonld"
fields="email"
widget-email="custom-form-widget-1"
></solid-form>
<solid-widget name="custom-form-widget-1">
<template>
<input type="text" data-holder />
</template>
</solid-widget>
<solid-form
data-src="../data/list/user-1.jsonld"
fields="email"
widget-email="custom-form-widget-2"
></solid-form>
<solid-widget name="custom-form-widget-2">
<template>
<input type="text" data-holder value="${value}" />
</template>
</solid-widget>
.. figure:: ../../_static/images/import_documentation/img-core-examples/data-holder-in-solid-widget.png
:alt: solid-widget with and without value="${value}" attribute
source/import_documentation/Mixins/counter-mixin.rst
View file @ 405339e9
......@@ -27,4 +27,3 @@ Attributes
fields="username"
counter-template="<strong>${counter} users here</strong>"
></solid-display>
source/import_documentation/Mixins/filter-mixin.rst
View file @ 405339e9
......@@ -20,7 +20,7 @@ Attributes
Target a ``<solid-form-search>`` used to filter current list of resource.
example:
Example:
.. code:: html
......@@ -41,8 +41,6 @@ Attributes
``search-fields`` **deprecated**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The properties you want to use to filter the list of resources.
You can add multiple fields, separated by a comma.
......
source/import_documentation/Mixins/grouper-mixin.rst
View file @ 405339e9
......@@ -54,7 +54,6 @@ Attributes
</template>
</solid-widget>
``group-class``
~~~~~~~~~~~~~~~
The name of the class to add on each group widget.
\ No newline at end of file
source/import_documentation/Mixins/next-mixin.rst
View file @ 405339e9
......@@ -20,7 +20,7 @@ Attributes
``next``
~~~~~~~~
`name` attribute of the ``<solid-route>`` that should be accessed when a ``<solid-display>``, ``<solid-map>`` or ``<solid-calendar>`` element is clicked.
``name`` attribute of the ``<solid-route>`` that should be accessed when a ``<solid-display>``, ``<solid-map>`` or ``<solid-calendar>`` element is clicked.
It can also be used to indicate the ``name`` attribute of the ``<solid-route>`` to reach after :
......
source/import_documentation/Mixins/server-pagination-mixin.rst 0 → 100644
View file @ 405339e9
.. _server-pagination-mixin:
server-pagination-mixin
================
The server-pagination mixin is a post-processor mixin, which provides the ability to handle the pagination server side, hence reducing the number of resources fetched on first call.
Used by:
--------
* :ref:`solid-display <solid-display>`
Attributes
----------
``limit``
~~~~~~~~~~~~~~~
The number of resources to fetch.
In this example, the list will show pages of 5 users.
.. code:: html
<solid-display
data-src=http://server/users/"
fields="username"
limit="5"
></solid-display>
``offset``
~~~~~~~~~~~~~~~
The offset of the first resource to fetch
In this example, the list will show pages of 5 users, skipping the first ten.
.. code:: html
<solid-display
data-src=http://server/users/"
fields="username"
limit="5"
offset="10"
></solid-display>
\ No newline at end of file
source/import_documentation/Mixins/store-mixin.rst
View file @ 405339e9
......@@ -35,6 +35,27 @@ Attributes
with the attribute ``bind-resources``) but you need to display
another field of this source.
The example below illustrates how to use nested-field attribute :
* The ``profile`` is a resource nested in the current resource, it will automatically fetch the ``city``, ``phone``, ``website`` values to display them.
* The second solid-display shows another way to display the values from a nested resource with dot ``.``.
.. code:: html
<solid-display
data-src="data/list/user-1.jsonld"
nested-field="profile"
fields="city, phone, website"
></solid-display>
<solid-display
data-src="data/list/user-1.jsonld"
fields="profile.city, profile.phone, profile.website"
></solid-display>
.. figure:: ../../_static/images/import_documentation/img-core-examples/nested-field.png
:alt: nested-field attribute use
.. _extra-context:
``extra-context``
~~~~~~~~~~~~~~~~~
......@@ -94,8 +115,9 @@ Attributes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*Available from version 0.13*
This mixin decode all attribute values starting by ``store://resource`` or
``store://user`` and replace them by the values fetched from the store.
This mixin decode all attribute values starting by ``store://resource``,
``store://container`` or ``store://user`` and replace them by the values fetched
from the store.
It can be a value fetched from the current resource or the current logged in user (works with ``sib-auth``).
......
source/import_documentation/Mixins/widget-mixin.rst
View file @ 405339e9
......@@ -9,7 +9,9 @@ Used by:
* :ref:`solid-display <solid-display>`
* :ref:`solid-form <solid-form>`
* :ref:`solid-form-search <solid-form-search>`
* :ref:`solid-map <solid-map>`
* :ref:`solid-table <solid-table>`
Attributes
......@@ -20,12 +22,14 @@ Attributes
~~~~~~~~~~
The ordered list of fields to be displayed, separated by commas.
By default, all the fields of the resource are displayed.
By default, all the fields of the resource are used.
To not show any fields, put an empty fields (eg.
``<solid-display fields />)``
``<solid-display fields />)``.
By default, all displayed fields are inserted into a ``<div>``
By default, all displayed fields are inserted into a ``<div>``.
It is possible to use the dot ``.`` to display data from a nested resource.
**Sets**
......@@ -41,7 +45,9 @@ Attributes
fields="fullName(first_name, last_name), email"
></solid-display>
You can customize the group widget, see the :ref:`Sets widgets <reference>` page for more info.
Make sure you don’t give your set the same name as a field as it would result in an infinite loop.
You can customize the group widget, see the :ref:`Sets widgets <reference>` page for more info.
**Strings**
......@@ -69,7 +75,6 @@ Attributes
value-title="My custom and static title"
></solid-display>
.. _default-field:
``default-[field]``
~~~~~~~~~~~~~~~~~~~
......@@ -97,7 +102,19 @@ Attributes
.. _action-field:
``action-[field]``
~~~~~~~~~~~~~~~~~~
Displays a link with a ``<solid-link>`` tag with the current resource as ``data-src`` and the value of the attribute as ``next``.
Displays a link with a ``<solid-link>`` tag with the current resource as ``data-src`` and
the value of the attribute as ``next``.
.. _link-text-field:
``link-text-[field]``
~~~~~~~~~~~~~~~~~~~~~
*Works only with solid-display-link(-mailto/tel/blank) and solid-action*
*Available from version 0.18*
Modify the displayed value as link in :
- ``<a>`` for solid-display-link,
- ``<solid-link>`` in solid-action.
.. _src-field:
``src-[field]``
......
source/import_documentation/Widgets/Examples.rst
View file @ 405339e9
.. _widgets-examples:
Examples
=========
......@@ -175,6 +177,71 @@ solid-set-div
*The border is applied on solid-set-div*
solid-action
~~~~~~~~~~~~
A classic example of solid-action use is a list of resources (users here) with only one field displayed and the possibility to access additionnal informations by clicking on "User details" :
.. code:: html
<solid-display
data-src="data/list/users.jsonld"
fields="name, details"
value-details="User details"
label-name="Name :"
widget-name="solid-display-value-label"
></solid-display>
.. figure:: ../../_static/images/import_documentation/widgets-examples/widget-action.png
:alt: Basic solid-display
This is the solid-display with action attribute and link-text-[field] attribute use to replace the basic value-[field] from above.
.. code:: html
<solid-display
data-src="data/list/users.jsonld"
fields="name, details"
label-name="Name :"
widget-name="solid-display-value-label"
action-details="user-details"
link-text-details="User details"
></solid-display>
.. figure:: ../../_static/images/import_documentation/widgets-examples/widget-action2.png
:alt: Widget solid-action
By adding a router, a route and another view, clicking on the solid-action displays the view (dotted border):
.. code:: html
<solid-router use-hash>
<solid-route
hidden
use-id
name="user-details"
></solid-route>
</solid-router>
<solid-display
data-src="data/list/users.jsonld"
fields="name, details"
label-name="Name :"
widget-name="solid-display-value-label"
action-details="user-details"
link-text-details="User details"
></solid-display>
<div data-view="user-details" hidden>
<solid-display
bind-resources
fields="first_name, last_name, username, email"
></solid-display>
</div>
.. figure:: ../../_static/images/import_documentation/widgets-examples/widget-action3.png
:alt: Widget solid-action with view
Step-by-step widget creation
----------------------------
......
source/import_documentation/Widgets/Reference.rst
View file @ 405339e9
......@@ -3,7 +3,9 @@
Widgets API Reference
=====================
Widgets are created at the moment you ask for it for the first time.
Widgets are tools that allow to choose, precise how to display data.
They are created at the moment you ask for it for the first time.
The name of the widget is analyzed to build a widget which uses the features and template you want.
Here is a schema of how it works:
......@@ -11,22 +13,31 @@ Here is a schema of how it works:
.. figure:: ../../_static/images/import_documentation/Widgets-API-Developers.png
:alt: Widget API 1
A widget is built like this.
``solid-[type]-[template]-[features]``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*All the keywords must be separated by ``-`` but can be put in any order.*
Its name must begin by "**solid-**", followed by at least a ``type`` (except for ``default`` type) and a ``template``, and eventually one or several ``features``.
*All the keywords must be separated by an hyphen``-``, it is recommended to keep that order (to harmonise widget names writing).*
``type``
++++++++
Can be ``display`` , ``form`` or ``set``. Will select the directory of template to use.
It refers to the "kind" of data to display :
- ``display`` refers to a display formatting,
- ``form`` to display a form element (``<input>``, ``<textarea>``, ``<select>``, etc),
- ``set`` to precise how to display values of fields in :ref:`sets <widget-mixin>`.
It will select the directory of template to use.
``template``
++++++++++++
Name of the template to use.
Each type has several templates. They specify how to use or display the value(s) and/or to indicate the HTML tag to use.
Name of the template to use. Available templates:
Available templates :
- ``display`` directory
......@@ -42,6 +53,7 @@ Name of the template to use. Available templates:
- ``textarea``: set ``value`` in a ``<textarea>``.
- ``richtext``: set ``value`` in an ``<div>`` and initialize a light rich text editor by using ``Quill``.
- ``checkbox``: create a checkbox, which is checked if ``value == true``.
- ``email``: set ``value`` in an ``<input>`` of type ``email``.
- ``date``: set ``value`` in an ``<input>`` of type ``date``.
- ``rangedate``: set 2 values in 2 ``<input>`` of type ``date``. Used for filtering with min and max.
Possible to add ``start-value-[field]`` and ``end-value-[field]`` attributes to set min and max values. Date format to follow : "YYYY-MM-DD". Each attribute accepts ``today`` as value.
......@@ -69,17 +81,17 @@ Name of the template to use. Available templates:
- ``div``: inserts widgets in a ``<div>`` tag.
- ``ul``: inserts widgets in a ``<ul>`` tag.
- **default** (no template keyword defined)
- **default** (no type keyword defined)
- ``action``: Displays a link inside a ``<solid-link>`` tag with ``src`` for the ``data-src`` attribute,
``value`` for the ``next`` attribute and ``label`` as text content.
``value`` for the ``next`` attribute and ``link-text`` as text content.
- ``multiple``: insert a ``solid-display`` with the ``@id`` of a container as ``data-src``.
The fields to display are chosen with the ``multiple-[field name]-fields`` attribute.
``features``
++++++++++++
Features to add to the widget. You can choose as many as you want
They allows to modify the behavior or the display of the widget. It is possible to add one or several features to the widget's name :
- ``label``: adds a ``label`` before the template. Uses the attribute ``name`` if ``label`` is not defined.
- ``labellast``: adds a ``label`` after the template. Uses the attribute ``name`` if ``label`` is not defined.
......
source/import_documentation/about/About-our-components.rst
View file @ 405339e9
.. _about-our-components:
About our components
######################
####################
**When you should create a component**
......
source/import_documentation/devops/commit_message_convention.rst deleted 100644 → 0
View file @ 32a1d64d
Convention about commit messages for Startin’blox
=================================================
Commit messages are used to automatically define the version bump of the
next release. Therefore they must reflect the nature of the modification
and the stability of the code.
The commit message should have this pattern: ``type: message``
With the possible commit types:
=========== ========= ================= ========= ============
Commit Type Title Description Release In changelog
=========== ========= ================= ========= ============
``minor`` Minor Minor release ``minor`` ``yes``
``major`` Major Major release ``major`` ``yes``
``feature`` Features New behavior ``patch`` ``yes``
``update`` Updates Change behavior ``patch`` ``yes``
``bugfix`` Bug Fixes Fix bugs ``patch`` ``yes``
``ui`` Interface Change appearance ``patch`` ``yes``
``syntax`` Syntax Refactoring code ``patch`` ``yes``
\ Other All others ``patch`` ``no``
=========== ========= ================= ========= ============
`See
reference <https://git.happy-dev.fr/startinblox/management#commit-messages>`__
source/import_documentation/devops/deploy_sib_application_on_alwaysdata.rst deleted 100644 → 0
View file @ 32a1d64d
Deploy a SIB application on alwaysdata
======================================
- Public: Startinblox dev and devops
- Requires: ``tech@startinblox.com`` permissions
Create account
--------------
1. Create the ``<app>`` account on the chosen server
2. Configure SSH access to the server
Configure a SIB server
----------------------
Installation
~~~~~~~~~~~~
1. From webadmin create a new ``<app>_db`` postgres database
2. Setup python default version to ``v3.6``
3. Configure a ``Python`` website:
- address: ``api.<app>.startinblox.com``
- type: ``Python WSGI``
- path: ``/sibserver/server/wsgi.py``
- workdir: ``/sibserver``
- python version: ``3.6.x``
- statics: ``/static/=/static/``
4. Connect through SSH to `Install a SIB
server <./install_sib_server>`__ with a **production** configuration
::
site_url: https://api.<app>.startinblox.com
allowed_hosts:
- api.<app>.startinblox.com
db_host: postgresql-<app>.alwaysdata.net
db_name: <app>_db
db_user: <app>
db_pass: <db pass>
smtp_host: smtp-<app>.alwaysdata.net
smtp_user: <app>@alwaysdata.net
smtp_pass: <email pass>
admin_email: admin@example.org
admin_name: admin
admin_pass: admin
xmpp_url: 'https://jabber.happy-dev.fr'
jabber_host: 'happy-dev.fr'
Note: Don’t forget to restart app after changing configuration.
Test the setup
~~~~~~~~~~~~~~
SMTP:
::
$ python sibserver/manage.py sendtestemail plup@plup.io
Configure the front application
-------------------------------
1. `Build your application <./build_sib_application>`__ with your
``https://api.<app>.startinblox.com`` URL
2. Transfer the ``dist`` folder content to a ``front`` folder on the
server
3. Configure a ``Static`` website:
- name: Front
- addresses: ``<app>.startinblox.com``
- type: Static files
- root folder: ``/front/``
source/import_documentation/devops/develop_sib_application.rst deleted 100644 → 0
View file @ 32a1d64d
Develop a new SIB application
=============================
FIXME: complete this section
source/import_documentation/devops/develop_sib_components.rst deleted 100644 → 0
View file @ 32a1d64d
Develop SIB components
======================
FIXME: complete this section
source/import_documentation/devops/develop_sib_ldp_packages.rst deleted 100644 → 0
View file @ 32a1d64d
Develop SIB server packages
===========================
Requirements
------------
- A `SIB server <./install_sib_server>`__ in development mode
Create your package
-------------------
From the project directory (the folder where the ``manage.py`` resides)
create a new package structure:
::
$ sib startpackage mypack
Add your package to the ``packages.yml``:
::
ldppackages:
mypack: mypack
Then initiate your server backend:
::
$ sib install sib_server
Note: It is important to run this command from the project directory in
order for the manager to find your package.
Finally, you can run your server as usual to see your new package’s
data.
source/import_documentation/devops/home.rst deleted 100644 → 0
View file @ 32a1d64d
Startin’Blox operational documentation
======================================
``SIB`` application capabilities relies on:
- Servers with ``LDP packages`` able to serve the data
- Clients with ``components`` able to manipulate the data
The SIB servers
---------------
Before deploying any SIB applications you will need SIB servers able to
provide all capabilities your application relies on.
SIB servers come with packages developed and `maintained by the
Startin’Blox
team <https://git.happy-dev.fr/startinblox/djangoldp-packages>`__. You
can pick up the ones you like or write your own.
Install a SIB server
~~~~~~~~~~~~~~~~~~~~
You can use any servers exposing data as LDP containers. But you will
likely setup your own to expose your data to others.
- `How to setup a SIB server <./install_sib_server>`__
Develop your own server packages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LDP packages represent capabilites the server could support. Each may
have it’s own configuration depending of what mission it fulfills. There
is no limit of what a LDP package can do.
- `How to develop LDP packages <./develop_sib_ldp_packages>`__
The SIB applications
--------------------
SIB applications are only HTML code binding together web components to
provide all the functionalities the application requires. Each component
can connect to multiple LDP servers providing the matching
functionality. As for the server packages, some SIB components are
developed and `maintained by the Startin’Blox
team <https://git.happy-dev.fr/startinblox/components>`__ but you can
write your owns.
Create an app with SIB components
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- `How to develop a SIB application <./develop_sib_application>`__
Developing your own components
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When developing a new SIB application you can use existing components or
create your owns.
- `How to develop SIB components <./develop_sib_components>`__
Build an existing SIB application
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The easiest to start with is to use an existing SIB application and
build it with your own configuration.
- `How to build an existing SIB
application <./build_sib_application>`__
SIB with Gitlab CI
------------------
- `How to set up automatic delivery for a SIB
application <./setup_continous_delivery_for_sib_application>`__
- `How to set up automatic delivery for
NPM <./setup_continous_delivery_for_node>`__
- `How to set up automatic delivery for
Pypi <./setup_continous_delivery_for_python>`__
SIB in docker
-------------
- `How to run SIB in docker containers <./sib_in_containers>`__
Contributing
------------
- `Architecture overview <./architecture_overview>`__
- `Convention for commit messages <./commit_message_convention>`__
- `Release workflow <./release_workflow>`__
- How to merge ``alpha`` in ``master`` ?
- How next ``alpha`` release is elected ?
Architecture
~~~~~~~~~~~~
Some general schema of the existing StartinBlox applications
architecture can be found
`here <https://docs.google.com/presentation/d/1iCRGaJpFvZjhjIUnpsn6lRTJJ31ES6n94BNkJygzUwM/edit?usp=sharing>`__.
source/import_documentation/devops/index.rst deleted 100644 → 0
View file @ 32a1d64d
Devops
==========
.. toctree::
:maxdepth: 2
:caption: Devops:
build_sib_application
commit_message_convention
deploy_sib_application_on_alwaysdata
develop_sib_application
develop_sib_components
develop_sib_ldp_packages
home
install_sib_server
manually_force_pushing_on_regitries
migrate_gitlab
release_workflow
setup_continous_delivery_for_node
setup_continous_delivery_for_python
setup_continous_delivery_for_sib_application
sib_in_containers
tests/node_release_management
\ No newline at end of file
source/import_documentation/devops/install_sib_server.rst deleted 100644 → 0
View file @ 32a1d64d
How to install a SIB server
===========================
Requirements
------------
The SIB server requires:
- python 3.6
- postgresql database (for production)
Initiate the server
-------------------
From a fresh environment, get the last version of the ``sib-manager``:
::
$ python -m pip install -U sib-manager
Create a project structure from a production template:
::
$ sib startproject sibserver --production
$ cd sibserver
For a development server remove the ``--production`` flag.
Configure your LDP packages
---------------------------
The configuration of the packages goes in ``packages.yml`` file in the
``ldppackages`` section. Those following ones are given as an example.
Yours depend on what your app does.
::
ldppackages:
djangoldp_circle: djangoldp_circle
djangoldp_account: djangoldp_account
djangoldp_profile: djangoldp_profile
oidc_provider: 'git+https://github.com/jblemee/django-oidc-provider.git@develop'
Details about ``packages.yml`` format are given in the template file.
Configure your server parameters
--------------------------------
The ``packages.yml`` files is also use to provide parameters to the
server itself.
Configure the server parameters in the ``packages.yml``:
::
server:
site_url: 'http://localhost:8000'
admin_email: admin@example.org
admin_name: admin
admin_pass: admin
This configuration works for a local development server but for a
production instance you need to setup a postgresql database and
configure dependent services:
::
server:
site_url: 'https://api.batman.happy-dev.fr'
allowed_hosts:
- api.batman.happy-dev.fr
db_host: postgresql-batman.happy-dev.fr
db_name: batman_db
db_user: batman
db_pass: changeit
smtp_host: smtp-batman.happy-dev.fr
smtp_user: batman
smtp_pass: changeit
admin_email: admin@example.org
admin_name: admin
admin_pass: changeit
xmpp_url: 'https://jabber.happy-dev.fr'
jabber_host: 'happy-dev.fr'
Launch the installation
-----------------------
Install/update the project:
::
$ sib install server
Launch the server
-----------------
Run the server in development:
::
$ python manage.py runserver 0.0.0.0:8000
To *launch the server in production*:
- you have to install the static files with
``python manage.py collectstatic``
- and you have to configure your python server to server the script:
``wsgi.py`` on the URL ``api.batman.happy-dev.fr/``.
Tips & tricks
-------------
Activate debug mode
^^^^^^^^^^^^^^^^^^^
To activate the debug mode (default in development) you can override
manually the ``DEBUG`` variable in the ``settings.py``
Install the server as a subfolder URL
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This method isn’t officially supported and requires to change values in
the core configuration.
To setup the SIB server on a subfolder
``https://batman.happy-dev.fr/api`` you have to manually override the
configuration in the ``settings.py``:
::
BASE_URL = 'https://batman.happy-dev.fr'
SITE_URL = 'https://batman.happy-dev.fr/api'
STATIC_URL = '/api/static/'
and URLs in ``urls.py``:
::
urlpatterns = [
url(r'^api/', include('djangoldp.urls')),
url(r'^api/admin/', admin.site.urls),
]
Note: Alwaysdata static config ``/api/static/=/static/``
source/import_documentation/devops/manually_force_pushing_on_regitries.rst deleted 100644 → 0
View file @ 32a1d64d
Manually force pushing on registries
====================================
**Tested for NPM only**
This a ``emergency`` procedure to force pushing on registries. It’s made
to be used when ``continuous delivery pipeline`` is down.
Requirements: This procedure requires authentication on the registries.
After you made your fix, determine the package version to release
(incremented from the last):
::
$ git pull --tags
$ git tag -l
v2.1.0
v2.2.0
Tag the new version to release first and update remote:
::
$ git tag -a 'v2.1.1'
$ git push --follow-tags
This step is important to keep coherency with the autorelease mecanism.
Edit the ``package.json`` to indicate to the registry the version we are
pushing:
::
$ vi package.json
{
"name": "plup-hello",
"version": "v2.1.1",
[truncated]
Push on regitry:
::
$ export NPM_TOKEN=<token>
$ echo '//registry.npmjs.org/:_authToken=${NPM_TOKEN}' > .npmrc
$ npm publish
And then reset the version as it is normally managed automatically:
::
$ git checkout -f
$ rm .npmrc