Package System in Meteor
Since version 0.9.0 (about a couple of months ago), the Meteor has updated the package system created on the basis of the Atmosphere . With the release of the new package system, the creation and publication of own packages became available to each user. As of today, the system has more than 1,800 packages and there are about 500 contributors.
About Meteor, Meteorite and Atmosphere have repeatedly written on Habré , but I want to share my experience in creating packages for this framework.
This article is about why we need the next package system, how to use it, how to create, test and publish packages.
')
Now there are at least two package systems about which every web developer has probably heard: npm and bower for client libraries. Each of them has thousands of packages, and npm also has several million daily downloads. So why not use these systems to deliver libraries to Meteor apps?
According to the authors themselves [2] of the new system, the main reason is the ability to run js code on various platforms: in the browser, on the server or on the phone - that is, now you can write your code on js once and run it anywhere, but with This may cause some problems.
The developers give the following example: let's say you want to create a service that will work with data from a third-party service using the REST API, for example, from the social network Facebook. On the client, you will need to use XMLHttpRequest functionality, on the server a module for NodeJS http, or various add-ons. In both cases, you write code in js, but it turns out to be non-portable, as a result of which you need to support two different versions.
The idea of Meteor is that with the help of the standard HTTP package you can write isomorphic code that will work equally on both the client and the server. Support for such isomorphism in Meteor extends even to packages for working with the database.
In Meteor, the package building system allows you to specify code to be executed on a specific platform or on several at once, even architecturally dependent code can be contained in packages. The system is able to correctly combine such code, and the build process itself can be expanded with the necessary functionality, since it is fully programmable. To all this, the build system can work not only with its packages, but also packages from npm or any other similar services.
Package names in Meteor have the following username format : packagename @ version , where username is the name of the contributor, packagename is the name of the package, and version is the corresponding version. The main packages that are part of Meteor itself do not contain the name of the author of the package, these are packages like http , coffeescript , standard-app-packages and others.
Further help on the commands below can be obtained by typing
To add a package, simply run the following instruction in the terminal in the project folder:
For example meteor add iron: router . To specify a specific version of the package, you can use meteor add username: packagename @ version , for example, we need a package with version 0.1.0 - we execute meteor add username: packagename@0.1.0 , in this case the specified version will be installed or higher, but compatible with 0.1.0 . To indicate the exact version, you need to write a = sign before the version: meteor add username: packagename@=0.1.0 . To remove a specific version you can simply type meteor add username: packagename .
To upgrade packages and Meteor as a whole, you can run
This command also supports several parameters: meteor update package1 package2 ... - updates only specified packages, meteor update –packages-only - updates all packages and will not update Meteor itself.
Removing packages is done through the command
The framework package system automatically resolves all dependencies, but it may contain only one version of a specific package; therefore, some restrictions may arise. For example, if package A and package B depend on package C of version 1.1.0, but the new version of package A depends on C@2.0.0, then launching meteor update will not update package A, as this will disrupt package B.
Also, the package system will not roll back versions of installed packages. For example, if you install package A, which contains package C in dependencies, but you have installed package C, with a version lower than that specified in package A dependencies, then package C will be updated to the new version, but if package A is deleted C version rollback will not occur.
All installed packages and versions (if they have been specified) are saved in the .meteor / packages file. This file may have something like the following:
The file can be edited manually and if Meteor was launched at the time of saving, the packages will be updated automatically. You can also use the command to view the list of installed packages and their versions.
See the full list of packages together with the installed dependencies and their versions in the .meteor / versions file
For detailed information about the package (available versions, descriptions, supported platforms and authors) you can enter
You can find the package you need by running the command
The search is performed by a substring, and all packages containing the substring in the full name will be included in the output. In principle, a regular expression can be passed to the request since the information about the packages is in MongoDB, and the request is formed approximately by the following expression packages.find ({name: new RegExp (substr)}) .
To prevent this manual from being too voluminous and to take a detailed look at all the points when creating a package, I suggest you look at the examples in a special repository . You can also clone the project and feel how it works, since all the examples are working.
To publish your own packages, you need to create an account on the Meteor website. And then log in to the computer from which the packages will be managed, using the command
Suppose you have already created your package, debugged and wrote tests. To share it with the community you need to execute just one command:
This command will automatically build a package located in the current directory and publish it on the server. Then you can try to find your package using the meteor search packagename team, or search for the package on the Atmosphere website.
To publish a new version of the package, just run the command without the –create flag .
After that, the package will also be assembled and published, but when publishing a new version, you need to change the number in package.js , otherwise an error will occur.
Some packages may contain code dependent on the architecture. Currently the system supports the following: 32-bit Linux, 64-bit Linux and Mac OS. To publish package versions for various architectures, you need to install Meteor on the computer with the required operating system, log in and run the command
It is not necessary to download the package itself to this computer, the system will automatically download it, assemble and publish it.
About Meteor, Meteorite and Atmosphere have repeatedly written on Habré , but I want to share my experience in creating packages for this framework.
This article is about why we need the next package system, how to use it, how to create, test and publish packages.
Main features of the package system
- Adding, updating and deleting packages used in the project from the command line;
- Listing installed packages;
- Package caching - there is no need to load identical packages for different projects each time;
- Search for packages in the remote repository, the search can also be carried out on cached packages;
- Versioning according to the Semantic Versioning specification and version control packages;
')
Why do we need another package distribution system?
Now there are at least two package systems about which every web developer has probably heard: npm and bower for client libraries. Each of them has thousands of packages, and npm also has several million daily downloads. So why not use these systems to deliver libraries to Meteor apps?
According to the authors themselves [2] of the new system, the main reason is the ability to run js code on various platforms: in the browser, on the server or on the phone - that is, now you can write your code on js once and run it anywhere, but with This may cause some problems.
The developers give the following example: let's say you want to create a service that will work with data from a third-party service using the REST API, for example, from the social network Facebook. On the client, you will need to use XMLHttpRequest functionality, on the server a module for NodeJS http, or various add-ons. In both cases, you write code in js, but it turns out to be non-portable, as a result of which you need to support two different versions.
The idea of Meteor is that with the help of the standard HTTP package you can write isomorphic code that will work equally on both the client and the server. Support for such isomorphism in Meteor extends even to packages for working with the database.
In Meteor, the package building system allows you to specify code to be executed on a specific platform or on several at once, even architecturally dependent code can be contained in packages. The system is able to correctly combine such code, and the build process itself can be expanded with the necessary functionality, since it is fully programmable. To all this, the build system can work not only with its packages, but also packages from npm or any other similar services.
Using
Package names in Meteor have the following username format : packagename @ version , where username is the name of the contributor, packagename is the name of the package, and version is the corresponding version. The main packages that are part of Meteor itself do not contain the name of the author of the package, these are packages like http , coffeescript , standard-app-packages and others.
Further help on the commands below can be obtained by typing
$ meteor help <command> Adding, updating and removing packages
To add a package, simply run the following instruction in the terminal in the project folder:
$ meteor add username:packagename For example meteor add iron: router . To specify a specific version of the package, you can use meteor add username: packagename @ version , for example, we need a package with version 0.1.0 - we execute meteor add username: packagename@0.1.0 , in this case the specified version will be installed or higher, but compatible with 0.1.0 . To indicate the exact version, you need to write a = sign before the version: meteor add username: packagename@=0.1.0 . To remove a specific version you can simply type meteor add username: packagename .
To upgrade packages and Meteor as a whole, you can run
$ meteor update This command also supports several parameters: meteor update package1 package2 ... - updates only specified packages, meteor update –packages-only - updates all packages and will not update Meteor itself.
Removing packages is done through the command
$ meteor remove username:packagename Dependencies and limitations
The framework package system automatically resolves all dependencies, but it may contain only one version of a specific package; therefore, some restrictions may arise. For example, if package A and package B depend on package C of version 1.1.0, but the new version of package A depends on C@2.0.0, then launching meteor update will not update package A, as this will disrupt package B.
Also, the package system will not roll back versions of installed packages. For example, if you install package A, which contains package C in dependencies, but you have installed package C, with a version lower than that specified in package A dependencies, then package C will be updated to the new version, but if package A is deleted C version rollback will not occur.
Search and display installed packages
All installed packages and versions (if they have been specified) are saved in the .meteor / packages file. This file may have something like the following:
# Meteor packages used by this project, one per line. # # 'meteor add' and 'meteor remove' will edit this file for you, # but you can also edit it by hand. standard-app-packages coffeescript http accounts-base mrt:jquery-ui mrt:moment mrt:nprogress The file can be edited manually and if Meteor was launched at the time of saving, the packages will be updated automatically. You can also use the command to view the list of installed packages and their versions.
$ meteor list See the full list of packages together with the installed dependencies and their versions in the .meteor / versions file
For detailed information about the package (available versions, descriptions, supported platforms and authors) you can enter
$ meteor show <package> You can find the package you need by running the command
$ meteor search <substr> The search is performed by a substring, and all packages containing the substring in the full name will be included in the output. In principle, a regular expression can be passed to the request since the information about the packages is in MongoDB, and the request is formed approximately by the following expression packages.find ({name: new RegExp (substr)}) .
Build and test packages
To prevent this manual from being too voluminous and to take a detailed look at all the points when creating a package, I suggest you look at the examples in a special repository . You can also clone the project and feel how it works, since all the examples are working.
Manage your packages
Developer Account
To publish your own packages, you need to create an account on the Meteor website. And then log in to the computer from which the packages will be managed, using the command
$ meteor login Publication
Suppose you have already created your package, debugged and wrote tests. To share it with the community you need to execute just one command:
$ meteor publish --create This command will automatically build a package located in the current directory and publish it on the server. Then you can try to find your package using the meteor search packagename team, or search for the package on the Atmosphere website.
To publish a new version of the package, just run the command without the –create flag .
$ meteor publish After that, the package will also be assembled and published, but when publishing a new version, you need to change the number in package.js , otherwise an error will occur.
Some packages may contain code dependent on the architecture. Currently the system supports the following: 32-bit Linux, 64-bit Linux and Mac OS. To publish package versions for various architectures, you need to install Meteor on the computer with the required operating system, log in and run the command
$ meteor publish-for-arch <username:packagename@version> It is not necessary to download the package itself to this computer, the system will automatically download it, assemble and publish it.
Links
Source: https://habr.com/ru/post/239323/
All Articles