(minor markup and other fixes) |
(native module macro stuff) |
||
Line 5: | Line 5: | ||
== Naming Guidelines == | == Naming Guidelines == | ||
* The name of a Node.js extension/library package must start with ''nodejs-'' then the upstream name or name used in the npm registry. For example: | * The name of a Node.js extension/library package must start with ''nodejs-'' then the upstream name or name used in the npm registry. For example: ''nodejs-foomodule1''. While it is uncommon for package's name to contain ''node'', it may be desirable to leave it in (unlike most other language's modules, where it is usually removed). For instance, the npm registry contains a ''uuid'' and a ''node-uuid'' module, which would need to be named ''nodejs-uuid'' and ''nodejs-node-uuid'', repsectively. | ||
* Application packages that mainly provide user-level tools that happen to be written for Node.js must follow the [[Packaging:NamingGuidelines|general naming guidelines]] instead. | * Application packages that mainly provide user-level tools that happen to be written for Node.js must follow the [[Packaging:NamingGuidelines|general naming guidelines]] instead. | ||
Line 25: | Line 25: | ||
|nodejs_version||e.g. 0.9.5||The currently installed version of Node.js. | |nodejs_version||e.g. 0.9.5||The currently installed version of Node.js. | ||
|- | |- | ||
|nodejs_sitelib||/usr/lib/node_modules||Where Node.js modules are installed | |nodejs_sitelib||/usr/lib/node_modules||Where Node.js modules written purely in JavaScript are installed | ||
|- | |||
|nodejs_sitearch||/usr/lib/node_modules||Where native C++ Node.js modules are installed | |||
|- | |- | ||
|nodejs_symlink_deps||/usr/lib/rpm/nodejs-symlink-deps||See [[#Symlinking Dependencies]] below. | |nodejs_symlink_deps||/usr/lib/rpm/nodejs-symlink-deps||See [[#Symlinking Dependencies]] below. | ||
Line 31: | Line 33: | ||
|nodejs_fixdep||/usr/lib/rpm/nodejs-fixdep||See [[#Correcting Dependencies]] | |nodejs_fixdep||/usr/lib/rpm/nodejs-fixdep||See [[#Correcting Dependencies]] | ||
|} | |} | ||
{{admon/note|Node does not support multiarch.|Since npm and the node interpreter have no knowledge of multiarch, <code>%nodejs_sitelib</code> and <code>%nodejs_sitearch</code> currently point to the same directory. The split is reserved in the event that the interpreter gains multiarch support or pure JavaScript modules move to ''/usr/share''.}} | |||
These macros are provided by the ''nodejs'' package. | These macros are provided by the ''nodejs'' package. | ||
During <code>%install</code> or when listing <code>%files</code> you can use the <code>%nodejs_sitelib</code> macro to specify where the installed modules are to be found. For instance: | During <code>%install</code> or when listing <code>%files</code> you can use the <code>%nodejs_sitelib</code> or <code>%nodejs_sitearch</code> macro to specify where the installed modules are to be found. For instance: | ||
<pre> | <pre> | ||
%files | %files | ||
# A pure JavaScript node module | |||
%{nodejs_sitelib}/foomodule/ | %{nodejs_sitelib}/foomodule/ | ||
# A native node module | |||
%{nodejs_sitearch}/barmodule/ | |||
</pre> | </pre> | ||
Revision as of 22:02, 16 January 2013
Original Author: T.C. Hollingsworth
Based on the guidelines of other interpreted languages like Ruby and Python.
Naming Guidelines
- The name of a Node.js extension/library package must start with nodejs- then the upstream name or name used in the npm registry. For example: nodejs-foomodule1. While it is uncommon for package's name to contain node, it may be desirable to leave it in (unlike most other language's modules, where it is usually removed). For instance, the npm registry contains a uuid and a node-uuid module, which would need to be named nodejs-uuid and nodejs-node-uuid, repsectively.
- Application packages that mainly provide user-level tools that happen to be written for Node.js must follow the general naming guidelines instead.
BuildRequires
To build a package containing Node.js files, you need to have:
BuildRequires: nodejs-devel
Macros
In Fedora 18 and later, as well as EPEL 6, the following macros are defined for you:
Macro | Normal Definition | Notes |
---|---|---|
__nodejs | /usr/bin/node | The Node.js interpreter |
nodejs_version | e.g. 0.9.5 | The currently installed version of Node.js. |
nodejs_sitelib | /usr/lib/node_modules | Where Node.js modules written purely in JavaScript are installed |
nodejs_sitearch | /usr/lib/node_modules | Where native C++ Node.js modules are installed |
nodejs_symlink_deps | /usr/lib/rpm/nodejs-symlink-deps | See #Symlinking Dependencies below. |
nodejs_fixdep | /usr/lib/rpm/nodejs-fixdep | See #Correcting Dependencies |
These macros are provided by the nodejs package.
During %install
or when listing %files
you can use the %nodejs_sitelib
or %nodejs_sitearch
macro to specify where the installed modules are to be found. For instance:
%files # A pure JavaScript node module %{nodejs_sitelib}/foomodule/ # A native node module %{nodejs_sitearch}/barmodule/
Using this macro instead of hardcoding the directory in the specfile ensures your spec remains compatible with the installed Node.js version even if the directory structure changes radically (for instance, if %nodejs_sitelib
moves into %{_datadir}
).
Automatic Requires and Provides
The nodejs package includes an automatic Requires and Provides generator that automatically adds versioned dependencies based on the information provided in a modules package.json file.
Provides
It also adds virtual provides in the form npm(<module name>)
to identify modules listed in the npm registry. If a module is not listed in the npm registry, it must not provide this. Modules that aren't listed in the npm registry should set private to true in their package.json file. If not, you must patch it to include that or use RPM's filtering mechanism to remove the Provides.
Correcting Dependencies
Occasionally the dependencies listed in package.json are inaccurate. For instance, the module may work with a newer version of a dependency than the one explictly listed in the package.json file. To make correcting such dependencies easier, the %nodejs_fixdep
macro is provided and may be used instead of RPM's usual filtering mechanism. This macro should be used in %prep
and will patch package.json to contain the correct dependency information.
To convert any dependency to not list a specific version, just call %nodejs_fixdep
with the npm module name of the dependency. This changes the version in package.json to *
. (Or adds one if it wasn't already listed.) For example:
%prep %setup -q -n package %nodejs_fixdep foomodule
You can also specify a version:
%prep %setup -q -n package %nodejs_fixdep foomodule '>2.0'
The second argument to %nodejs_fixdep
must be a valid package.json version specifier as explained in
.
man npm json
You can also remove a dependency:
%prep %setup -q -n package %nodejs_fixdep -r foomodule
Symlinking Dependencies
Node.js and npm require that dependencies explicitly be included or linked into a node_modules directory inside the module directory. To make this easier, a %nodejs_symlink_deps
macro is provided and will automatically create a node_modules tree with symlinks for each dependency listed in package.json. This macro should be called in the %install
section of every Node.js module package.