summaryrefslogtreecommitdiffstats
path: root/meta/classes/npm.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* npm: remove some temporary build filesJean-Marie LEMETAYER2019-06-071-0/+1
| | | | | | | | | | | | | | | | | | | | Fixes [YOCTO #11028] When dealing with node modules which use "node-gyp" [1] to build native addons to node. Some temporary build files stay in the image: object files, static library files, dependency files, ... This commit does not keep only the required files, but remove the files which can leads to QA issues (staticdev with static library files). [1]: https://github.com/nodejs/node-gyp (From OE-Core rev: b03743b0f843736c6ebe8077e1e03bc03ac39410) Signed-off-by: Jean-Marie LEMETAYER <jean-marie.lemetayer@savoirfairelinux.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* npm: fix node and npm default directory conflictJean-Marie LEMETAYER2019-06-071-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes [YOCTO #13349] When dealing with node modules which have declared "bin" files [1], npm will create a link in '/usr/bin' with a relative link to '../lib/node_modules/<module bin file>'. The commits e9270af4296ce2af292059617a717e42fc17425c and 2713d9bcc39c712ef34003ce8424416441be558e explicitely use '/usr/lib/node/' as install directory, but does not care about the "bin" symbolic linked files. In order to keep valid links, and to keep it as simple as possible, the path '/usr/lib/node_modules/' is used as install directory for npm. And a symbolic link is created to have a valid '/usr/lib/node/' path, needed for node. [1]: https://docs.npmjs.com/files/package.json#bin (From OE-Core rev: 67846b3b2d2d45401d500bff5cf3d4d71c003f7a) Signed-off-by: Jean-Marie LEMETAYER <jean-marie.lemetayer@savoirfairelinux.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* npm: get npm package name from npm packJean-Marie LEMETAYER2019-06-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Fixes [YOCTO #12534] When using npm packages with exotic names, like "JSONSelect" (with uppercase) or "@angular/cli" (with at sign and slash), there are three different names: - the recipe name ("jsonselect" or "angular-cli") - the npm module name ("JSONSelect" or "@angular/cli") - the npm pack name ("JSONSelect" or "angular-cli") The commit fa9c077068a2acea04389fa2b44eb2e93548fce2 allow to have different recipe name and npm module name by setting the NPMPN variable. This commit allows to have yet another npm pack name. The pack filename is now dynamically retrieved from the 'npm pack' command. (From OE-Core rev: 86c9f25d4535663606326e53c33a8927f79e8f52) Signed-off-by: Jean-Marie LEMETAYER <jean-marie.lemetayer@savoirfairelinux.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* npm.bbclass: allow overriding NPM_INSTALL_DEVJef Driesen2018-10-251-1/+1
| | | | | | | | | | | Commit b1f10b18eaf6c8009e86863ca4a26f429de97082 added the NPM_INSTALL_DEV variable. But due to the use of simple assignment, a recipe can't override its value. (From OE-Core rev: b53d5094d5e05f9c1955c8565d777ad74f668f7e) Signed-off-by: Jef Driesen <jef.driesen@niko.eu> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* npm: change install directory to upstream defaultRichard Purdie2018-10-251-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The node binary searches for packages in a number of locations, the last of which is $PREFIX/lib/node (here: /usr/lib/node) from the list of GLOBAL_FOLDERS [1]. So change the installation directory for all packages depending on npm.bbclass to that location. This removes the need to define the NODE_PATH variable to the non-standard /usr/lib/node_modules value. While the Tips for Package Managers [2] discusses installing packages to /usr/lib/node_modules/<name>/<version>, this has several drawbacks: * it does not work for the REPL as mentioned in the documentation * it also does not work for any code _not_ installed as a global package under /usr/lib/node_modules (e.g. /usr/share/foo.js will not find any packages below /usr/lib) * using the non-default location and then having to set NODE_PATH barely saves any time: there are only two file-system lookups (to the legacy $HOME/.node_modules and $HOME/.node_libraries) directories before the library would be found And the suggestion was made in the context of deduping the node_modules tree by installing all packages in a flat hierarchy and using symlinks to the correct version of each dependency. This is not what OpenEmbedded does, so none of those benefits (deduping, cleaner packages) are being had by shifting the installation directory to /usr/lib/node_modules. The choice of a "proper" installation path is not helped by npm installing to /usr/lib/node_modules if asked to install globally. Still, using the location expected by nodejs (/usr/lib/node) seems the right choice. [1]: https://nodejs.org/api/modules.html#modules_loading_from_the_global_folders [2]: https://nodejs.org/api/modules.html#modules_addenda_package_manager_tips (From OE-Core rev: c73bc49038effd64f2c2542c1f4da8b6a4168477) Signed-off-by: Olaf Mandel <o.mandel@menlosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* npm: change install directory to upstream defaultOlaf Mandel2018-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The node binary searches for packages in a number of locations, the last of which is $PREFIX/lib/node (here: /usr/lib/node) from the list of GLOBAL_FOLDERS [1]. Change the installation directory for all packages depending on npm.bbclass to that location. This removes the need to define the NODE_PATH variable to the non-standard /usr/lib/node_modules value. While the Tips for Package Managers [2] discusses installing packages to /usr/lib/node_modules/<name>/<version>, this has several drawbacks: * it does not work for the REPL as mentioned in the documentation * it also does not work for any code _not_ installed as a global package under /usr/lib/node_modules (e.g. /usr/share/foo.js will not find any packages below /usr/lib) * using the non-default location and then having to set NODE_PATH barely saves any time: there are only two file-system lookups (to the legacy $HOME/.node_modules and $HOME/.node_libraries) directories before the library would be found And the suggestion was made in the context of deduping the node_modules tree by installing all packages in a flat hierarchy and using symlinks to the correct version of each dependency. This is not what OpenEmbedded does, so none of those benefits (deduping, cleaner packages) are being had by shifting the installation directory to /usr/lib/node_modules. [1]: https://nodejs.org/api/modules.html#modules_loading_from_the_global_folders [2]: https://nodejs.org/api/modules.html#modules_addenda_package_manager_tips (From OE-Core rev: 2036137151929b541293154ff529475071cd92b0) Signed-off-by: Olaf Mandel <o.mandel@menlosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* npm.bbclass: Node module name and recipe name can be differentBöszörményi Zoltán2018-02-061-5/+13
| | | | | | | | | | | | Some NPM modules have the same name as their low level dependencies. To prevent recipe naming conflicts, allow node module recipe names to start with the "node-" prefix. (From OE-Core rev: 6b417c7c3a38463c64756beae9817fa2a80fd09e) Signed-off-by: Zoltán Böszörményi <zboszor@pr.hu> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* npm.bbclass: Fix building node modules with npm@5Böszörményi Zoltán2018-02-061-2/+3
| | | | | | | | | | | | | | | | | | | | npm cache clear throws an error with npm@5 and suggests to use npm cache verify instead. But our cache is actually empty, so use npm cache clear --force. npm install in the source directory creates symlinks with npm@5. Use a combination of npm pack and npm install module-version.tgz that works the same way with older and new npm versions and is guaranteed to create actual copies instead of directory symlinks. This change allows using nodejs 8.x LTS, tested with 8.9.4. (From OE-Core rev: 2d7d2a460842c8747df17990970f22f4a11f36f6) Signed-off-by: Zoltán Böszörményi <zboszor@pr.hu> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/npm: allow installation of devDependenciesAnders Darander2017-03-221-2/+11
| | | | | | | | | | | | | | Often, eg when using angular2, there's a need to install also the devDependencies. The default is to keep the old behaviour, to not install devDependencies. (From OE-Core rev: 9377d16751aeff0a913e754d711bca6e4e4d9df1) Signed-off-by: Anders Darander <anders@chargestorm.se> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/npm: set HOME during do_installPaul Eggleton2017-02-071-0/+3
| | | | | | | | | | | In do_compile we set HOME so that ~/.npm* only get created in the work directory; we need to do the same in do_install as well or they'll go into the user's home directory which we do not want. (From OE-Core rev: a667cb9ed2dceb804b85d1a024e2619bc34d2681) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta: remove True option to getVar callsJoshua Lock2016-12-161-2/+2
| | | | | | | | | | | | | getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?\(( ?[^,()]*), True\) (From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/npm: use npm install to do installationPaul Eggleton2016-11-061-1/+5
| | | | | | | | | | | | | | | Using "npm install" instead of "cp -a" is the more correct thing to be doing here, and ensures that symlinks for executable scripts are put into ${prefix}/bin. (I'd prefer ${bindir}, but npm does not allow specifying paths at that level - only a prefix.) Fixes [YOCTO #10460]. (From OE-Core rev: 90cb980a1c49de99a0aec00c0cd5fc1e165490a7) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: support node.js code outside of npmPaul Eggleton2016-09-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | If you have your own node.js application you may not publish it (or at least not immediately) in an npm registry - it might just be in a repository on github or on your local machine. Add support to recipetool create for creating recipes to build such applications - extract their dependencies, fetch them, and add corresponding npm:// URLs to SRC_URI, and ensure that LICENSE / LIC_FILES_CHKSUM are updated to match. For example, you can now run: recipetool create https://github.com/diversario/node-ssdp (I had to borrow some code from bitbake/lib/bb/fetch2/npm.py to implement this functionality; this should be refactored out but now isn't the time to do that refactoring.) Part of the fix for [YOCTO #9537]. (From OE-Core rev: 4fb8b399c05a1b66986fc76e13525f6c5e0d9b58) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* npm: npm.bbclass now adds nodejs to RDEPENDSHenry Bruce2016-08-171-0/+1
| | | | | | | | | | | We expect that any package that uses the npm bbclass will have a runtime dependency on node.js (From OE-Core rev: 769fae0b74d7c7992aa593907f446fab98ef5128) Signed-off-by: Henry Bruce <henry.bruce@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* npm.bbclass: avoid str/byte conversion problems for PKGV and SUMMARYPatrick Ohly2016-06-121-2/+2
| | | | | | | | | | | | | | | | | In Python3, str.encode() returns byte strings, which later are not converted back to strings automatically, leading to "TypeError: Can't convert 'bytes' object to str implicitly" in code which reads PKGV and SUMMARY and expects to find strings there. The npm.bbclass must use values for d.setVar() that meet that expectation, and thus the redundant (and in Python3, harmful) .encode() gets removed. (From OE-Core rev: 241e094bcd9212204350f9855257474908f82a3c) Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* npm: add target_arch flag to npmBrendan Le Foll2016-05-301-1/+12
| | | | | | | | | | | | | npm takes a target_arch flag which needs to be set to do some gyp compilations correctly. It also doesn't use the same mapping as OE for target arch so a small function is required to make the mapping work. Function is taken from meta-nodejs (From OE-Core rev: f402225311e4bbb62ba9781ab274420abaac0fb4) Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* npm.bbclass: Stop packagenames containing underscores from being generatedBrendan Le Foll2016-04-141-2/+4
| | | | | | | | | | | Package names cannot contain underscores yet some npm modules use them as part of the name, replace them with hyphens in the package name. (From OE-Core rev: fea932c79c8201e3e7649f4443874ea540e33461) Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add: delete externalsrc files on npm recipe do_installPaul Eggleton2016-03-251-2/+4
| | | | | | | | | | | | | | The npm class just installs whatever is in ${S}; if you're using externalsrc in conjunction with it the symlinks (oe-workdir and oe-logs by default) plus singletask.lock will end up in the final package, which isn't really right. Introduce a variable so we know the path the files will be installed into within npm.bbclass, and append to do_install within the workspace bbappend to delete the files. (From OE-Core rev: 766845e06db9d7d595e836ea1364c16fa132a413) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipetool: create: split npm module dependencies into packagesPaul Eggleton2016-03-091-0/+20
| | | | | | | | | | | | | | | | | | | | Rather than rolling all of an npm module's dependencies into the same package, split them into one module per package, setting the SUMMARY and PKGV values from the package.json file for each package. Additionally, mark each package with the appropriate license using the license scanning we already do, falling back to the license stated in the package.json file for the module if unknown. All of this is mostly in aid of ensuring all modules and their licenses now show up in the manifests for the image. Additionally we set the main LICENSE value more concretely once we've calculated the per-package licenses, since we have more information at that point. (From OE-Core rev: 8226805f83d21e7c1d2ba21969f3e8ee4b137496) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* npm.bbclass: Add npm class to match fetcherBrendan Le Foll2016-02-281-0/+25
npm class supports the npm fetcher, helping doing the basic compile/install stages of an npm package (From OE-Core rev: 4d2ad3e39242c947612023f4429bc8fb430551b5) Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-15 10:53:22 +0000