Related
I have created one angular library using angular 8 and CLI 8. I am trying to build the library, but I am getting the error.
ng build <lib-name>
I have gone through some questions posted related to this error, most of them say remove node_modules and reinstall them. I tried this solution but still, I am getting the following error.
[Browserslist] Could not parse package.json. Ignoring it.
ERROR: Unknown version 67 of android
Unknown version 67 of android
BrowserslistError: Unknown version 67 of android
at Function.select (C:\Users\kaukhare\github\ngx-group-by-alphabates\node_modules\ng-packagr\node_modules\autoprefixer\node_modules\browserslist\index.js:924:17)
at C:\Users\kaukhare\github\ngx-group-by-alphabates\node_modules\ng-packagr\node_modules\autoprefixer\node_modules\browserslist\index.js:252:33
at Array.reduce (<anonymous>)
at resolve (C:\Users\kaukhare\github\ngx-group-by-alphabates\node_modules\ng-packagr\node_modules\autoprefixer\node_modules\browserslist\index.js:234:18)
at browserslist (C:\Users\kaukhare\github\ngx-group-by-alphabates\node_modules\ng-packagr\node_modules\autoprefixer\node_modules\browserslist\index.js:353:16)
at Browsers.parse (C:\Users\kaukhare\github\ngx-group-by-alphabates\node_modules\ng-packagr\node_modules\autoprefixer\lib\browsers.js:66:12)
at new Browsers (C:\Users\kaukhare\github\ngx-group-by-alphabates\node_modules\ng-packagr\node_modules\autoprefixer\lib\browsers.js:48:26)
at loadPrefixes (C:\Users\kaukhare\github\ngx-group-by-alphabates\node_modules\ng-packagr\node_modules\autoprefixer\lib\autoprefixer.js:101:20)
at plugin (C:\Users\kaukhare\github\ngx-group-by-alphabates\node_modules\ng-packagr\node_modules\autoprefixer\lib\autoprefixer.js:112:20)
at LazyResult.run (C:\Users\kaukhare\github\ngx-group-by-alphabates\node_modules\postcss\lib\lazy-result.js:295:14)
at LazyResult.sync (C:\Users\kaukhare\github\ngx-group-by-alphabates\node_modules\postcss\lib\lazy-result.js:281:26)
at LazyResult.warnings (C:\Users\kaukhare\github\ngx-group-by-alphabates\node_modules\postcss\lib\lazy-result.js:85:17)
at StylesheetProcessor.process (C:\Users\kaukhare\github\ngx-group-by-alphabates\node_modules\ng-packagr\lib\ng-v5\entry-point\resources\stylesheet-processor.js:47:16)
at Object.readResource (C:\Users\kaukhare\github\ngx-group-by-alphabates\node_modules\ng-packagr\lib\ts\cache-compiler-host.js:73:57)
at TsCompilerAotCompilerTypeCheckHostAdapter.loadResource (C:\Users\kaukhare\github\ngx-group-by-alphabates\node_modules\#angular\compiler-cli\src\transformers\compiler_host.js:495:37)
at Object.get (C:\Users\kaukhare\github\ngx-group-by-alphabates\node_modules\#angular\compiler\bundles\compiler.umd.js:26490:94)
What can be the issue? Is this error is due to autoprefixer? What should I do to solve this issue?
package-lock.json
"ng-packagr": {
"version": "5.5.1",
"resolved": "https://registry.npmjs.org/ng-packagr/-/ng-packagr-5.5.1.tgz",
"integrity": "sha512-GT6QK5WAirQwALdeJPiXdgRd5PzRqcknb/C/G+cCDEbUFri4oGVmns2Nl4I0FGg/cRn6nXTxRiUunOSqZ3Lehw==",
"dev": true,
"requires": {
"ajv": "^6.10.2",
"autoprefixer": "^9.6.0",
"browserslist": "^4.0.0"
},
"autoprefixer": {
"version": "9.5.1",
"resolved": "https://registry.npmjs.org/autoprefixer/-/autoprefixer-9.5.1.tgz",
"integrity": "sha512-KJSzkStUl3wP0D5sdMlP82Q52JLy5+atf2MHAre48+ckWkXgixmfHyWmA77wFDy6jTHU6mIgXv6hAQ2mf1PjJQ==",
"dev": true,
"requires": {
"browserslist": "^4.5.4",
"caniuse-lite": "^1.0.30000957",
"normalize-range": "^0.1.2",
"num2fraction": "^1.2.2",
"postcss": "^7.0.14",
"postcss-value-parser": "^3.3.1"
}
The thing that solved it for me was running
npx browserslist --update-db
in project root. This made changes to package-lock.json updating versions of caniuse-lite.
To give some context, I landed on this question because I was getting this error:
Compiling TypeScript sources through ngc
ERROR: Unknown version 80 of android
An unhandled exception occurred: Unknown version 80 of android
after I upgraded angular from 9.x.x to 10.x.x.
I was getting this error both on my dev machine and in CI, so removing node_modules and package-lock.json was not really an option.
I'm seeing this too... like you, deleting node_modules and re-running npm install did not work.
What did work, however, was deleting node_modules AND deleting package-lock.json, and then running npm i.
Try that...
Andrew
This might be too late, but I'm gonna post how I solved the issue, because I ran into it very recently (late Feb. 2022), and I followed a different approach that resulted in minimal changes to my project.
I had a similar issue with a project downloaded from StackBlitz, but in my case the unknown version of android was 97 instead of 67 or 80.
The browserslist database was up to date, deleting the node_modules directory and running npm install did not change anything (checked by using a comparison tool), updating the project's dependencies caused even more trouble, and so did deleting package-lock.json.
What worked in my case was specifying 98 as the target version of android (instead of 97) in .browserslistrc in the project's root directory (I actually had to create that file, as it didn't exist).
This is how I found out that version 98 works:
I first temporarily edited the code where the exception occurred (in node_modules\browserslist\index.js). Right before the line that throws the exception, I inserted this statement:
if (name === 'android') {
return arguments.callee(context, name, (version - 1).toString())
}
to find the largest number less than 97 that is accepted. Then I ran npx browserslist and found that version to be 4.
Dissatisfied, I tried larger version numbers by replacing the above snippet with this one:
if (name === 'android' && Number(version) < 200) {
return arguments.callee(context, name, (Number(version) + 1).toString())
}
and fortunately, 98 worked (verified by running npx browserslist again).
So I undid my changes to the code, grabbed that output from npx browserslist, and saved it in .browserslistrc (I also had to exclude safari due to another bug).
The ng build command then proceeded successfully.
Try this:
1.Deleting the entire node_modules directory.
2.Deleting package-lock.json from the root directory.
3.Making sure the latest #angular-devkit projects were referenced in package.json:
"#angular-devkit/build-angular": "^0.801.3", "#angular-devkit/build-ng-packagr": "^0.801.3".
4.Close and reopen cmd window.
Running npm install.
I updated all the npm packages and the error went away.
Can be caused by outdated babel. Try update babel using npx babel-upgrade --write and then npx browserslist#latest --update-db.
TL;DR;
Your .browserslistrc entries might be invalid, or suddenly not understood by some of your packages. Try to remove/replace them.
I encountered this after installing
#angular-architects/module-federation on an Angular project.
My existing .browserslistrc was:
> 0.5%
last 2 versions
Firefox ESR
not dead
not IE 9-11 # For IE 9-11 support, remove 'not'.
Somehow after the above package got installed, the following error showed up :
BrowserslistError: Unknown version 103 of android
Just commented out my .browserslistrc entries, and got rid of this.
No idea why a package installation would cause this
Try to modify \node_modules\ng-packagr\node_modules\autoprefixer\node_modules\browserslist\index.js at row 924 as follow:
if (alias) {
version = alias
} else if (context.ignoreUnknownVersions) {
return []
} else {
throw new BrowserslistError(
'Unknown version ' + version + ' of ' + name)
}
in
if (alias) {
version = alias
} else if (context.ignoreUnknownVersions) {
return []
} else {
return []
}
I hope help you... this is dirty solution...
I'm finding myself in an Ember-based app and are having a little trouble understanding how I should add the chai-as-promised helper library to it. I'm running this version:
$ ember --version
version: 2.4.2
node: 5.8.0
os: darwin x64
I started by installing via npm i chai-as-promised --save-dev. The library was then importable via Node. Then I have tried adding it to the ember-cli-build.js file using two different approaches:
As a file via .import(), after creating the EmberApp:
module.exports = function(defaults) {
var app = new EmberApp([...]);
app.import('./node_modules/chai-as-promised/lib/chai-as-promised.js');
Via EmberApp.toTree() to chai-as-promised's top directory:
return app.toTree('./node_modules/ember-cli-blueprint-test-helpers/');
And descending into the lib/ subdirectory of chai-as-promised:
return app.toTree('./node_modules/chai-as-promised/lib');
I also tried installing via Bower and changing the above node_modules/ based paths to bower_components ones, but still with the same result.
Am I importing it wrong? Or is there somewhere else I should import?
You need to tell ember-cli to add it to the test tree like this:
app.import("bower_components/chai-as-promised/lib/chai-as-promised.js",
{ type: 'test' });
otherwise it isn't available in the test suite but in the app. I got this to work in combination with ember-cli-mocha.
You can see how it works here: https://github.com/albertjan/ember-cli-chai-as-promised
I was about to publish a module to NPM, when I thought about rewriting it in ES6, to both future-proof it, and learn ES6. I've used Babel to transpile to ES5, and run tests. But I'm not sure how to proceed:
Do I transpile, and publish the resulting /out folder to NPM?
Do I include the result folder in my Github repo?
Or do I maintain 2 repos, one with the ES6 code + gulp script for Github, and one with the transpiled results + tests for NPM?
In short: what steps do I need to take to publish a module written in ES6 to NPM, while still allowing people to browse/fork the original code?
The pattern I have seen so far is to keep the es6 files in a src directory and build your stuff in npm's prepublish to the lib directory.
You will need an .npmignore file, similar to .gitignore but ignoring src instead of lib.
I like José's answer. I've noticed several modules follow that pattern already. Here's how you can easily implement it with Babel6. I install babel-cli locally so the build doesn't break if I ever change my global babel version.
.npmignore
/src/
.gitignore
/lib/
/node_modules/
Install Babel
npm install --save-dev babel-core babel-cli babel-preset-es2015
package.json
{
"main": "lib/index.js",
"scripts": {
"prepublish": "babel src --out-dir lib"
},
"babel": {
"presets": ["es2015"]
}
}
TL;DR - Don't, until ~October 2019. The Node.js Modules Team has asked:
Please do not publish any ES module packages intended for use by Node.js until [October 2019]
2019 May update
Since 2015 when this question was asked, JavaScript support for modules has matured significantly, and is hopefully going to be officially stable in October 2019. All other answers are now obsolete or overly complicated. Here is the current situation and best practice.
ES6 support
99% of ES6 (aka 2015) has been supported by Node since version 6. The current version of Node is 12. All evergreen browsers support the vast majority of ES6 features. ECMAScript is now at version 2019, and the versioning scheme now favors using years.
ES Modules (aka ECMAScript modules) in browsers
All evergreen browsers have been supporting import-ing ES6 modules since 2017. Dynamic imports are supported by Chrome (+ forks like Opera and Samsung Internet) and Safari. Firefox support is slated for the next version, 67.
You no longer need Webpack/rollup/Parcel etc. to load modules. They may be still useful for other purposes, but are not required to load your code. You can directly import URLs pointing to ES modules code.
ES modules in Node
ES modules (.mjs files with import/export) have been supported since Node v8.5.0 by calling node with the --experimental-modules flag. Node v12, released in April 2019, rewrote the experimental modules support. The most visible change is that the file extension needs to be specified by default when importing:
// lib.mjs
export const hello = 'Hello world!';
// index.mjs:
import { hello } from './lib.mjs';
console.log(hello);
Note the mandatory .mjs extensions throughout. Run as:
node --experimental-modules index.mjs
The Node 12 release is also when the Modules Team asked developers to not publish ES module packages intended for use by Node.js until a solution is found for using packages via both require('pkg') and import 'pkg'. You can still publish native ES modules intended for browsers.
Ecosystem support of native ES modules
As of May 2019, ecosystem support for ES Modules is immature. For example, test frameworks like Jest and Ava don't support --experimental-modules. You need to use a transpiler, and must then decide between using the named import (import { symbol }) syntax (which won't work with most npm packages yet), and the default import syntax (import Package from 'package'), which does work, but not when Babel parses it for packages authored in TypeScript (graphql-tools, node-influx, faast etc.) There is however a workaround that works both with --experimental-modules and if Babel transpiles your code so you can test it with Jest/Ava/Mocha etc:
import * as ApolloServerM from 'apollo-server'; const ApolloServer = ApolloServerM.default || ApolloServerM;
Arguably ugly, but this way you can write your own ES modules code with import/export and run it with node --experimental-modules, without transpilers. If you have dependencies that aren't ESM-ready yet, import them as above, and you'll be able to use test frameworks and other tooling via Babel.
Previous answer to the question - remember, don't do this until Node solves the require/import issue, hopefully around October 2019.
Publishing ES6 modules to npm, with backwards compatibility
To publish an ES module to npmjs.org so that it can be imported directly, without Babel or other transpilers, simply point the main field in your package.json to the .mjs file, but omit the extension:
{
"name": "mjs-example",
"main": "index"
}
That's the only change. By omitting the extension, Node will look first for an mjs file if run with --experimental-modules. Otherwise it will fall back to the .js file, so your existing transpilation process to support older Node versions will work as before — just make sure to point Babel to the .mjs file(s).
Here's the source for a native ES module with backwards compatibility for Node < 8.5.0 that I published to NPM. You can use it right now, without Babel or anything else.
Install the module:
npm install local-iso-dt
# or, yarn add local-iso-dt
Create a test file test.mjs:
import { localISOdt } from 'local-iso-dt/index.mjs';
console.log(localISOdt(), 'Starting job...');
Run node (v8.5.0+) with the --experimental-modules flag:
node --experimental-modules test.mjs
TypeScript
If you develop in TypeScript, you can generate ES6 code and use ES6 modules:
tsc index.js --target es6 --modules es2015
Then, you need to rename *.js output to .mjs, a known issue that will hopefully get fixed soon so tsc can output .mjs files directly.
#Jose is right. There's nothing wrong with publishing ES6/ES2015 to NPM but that may cause trouble, specially if the person using your package is using Webpack, for instance, because normally people ignore the node_modules folder while preprocessing with babel for performance reasons.
So, just use gulp, grunt or simply Node.js to build a lib folder that is ES5.
Here's my build-lib.js script, which I keep in ./tools/ (no gulpor grunt here):
var rimraf = require('rimraf-promise');
var colors = require('colors');
var exec = require('child-process-promise').exec;
console.log('building lib'.green);
rimraf('./lib')
.then(function (error) {
let babelCli = 'babel --optional es7.objectRestSpread ./src --out-dir ./lib';
return exec(babelCli).fail(function (error) {
console.log(colors.red(error))
});
}).then(() => console.log('lib built'.green));
Here's a last advice: You need to add a .npmignore to your project. If npm publish doesn't find this file, it will use .gitignore instead, which will cause you trouble because normally your .gitignore file will exclude ./lib and include ./src, which is exactly the opposite of what you want when you are publishing to NPM. The .npmignore file has basically the same syntax of .gitignore (AFAIK).
Following José and Marius's approach, (with update of Babel's latest version in 2019): Keep the latest JavaScript files in a src directory, and build with npm's prepublish script and output to the lib directory.
.npmignore
/src
.gitignore
/lib
/node_modules
Install Babel (version 7.5.5 in my case)
$ npm install #babel/core #babel/cli #babel/preset-env --save-dev
package.json
{
"name": "latest-js-to-npm",
"version": "1.0.0",
"description": "Keep the latest JavaScript files in a src directory and build with npm's prepublish script and output to the lib directory.",
"main": "lib/index.js",
"scripts": {
"prepublish": "babel src -d lib"
},
"keywords": [],
"author": "",
"license": "ISC",
"devDependencies": {
"#babel/cli": "^7.5.5",
"#babel/core": "^7.5.5",
"#babel/preset-env": "^7.5.5"
},
"babel": {
"presets": [
"#babel/preset-env"
]
}
}
And I have src/index.js which uses the arrow function:
"use strict";
let NewOneWithParameters = (a, b) => {
console.log(a + b); // 30
};
NewOneWithParameters(10, 20);
Here is the repo on GitHub.
Now you can publish the package:
$ npm publish
...
> latest-js-to-npm#1.0.0 prepublish .
> babel src -d lib
Successfully compiled 1 file with Babel.
...
Before the package is published to npm, you will see that lib/index.js has been generated, which is transpiled to es5:
"use strict";
var NewOneWithParameters = function NewOneWithParameters(a, b) {
console.log(a + b); // 30
};
NewOneWithParameters(10, 20);
[Update for Rollup bundler]
As asked by #kyw, how would you integrate Rollup bundler?
First, install rollup and rollup-plugin-babel
npm install -D rollup rollup-plugin-babel
Second, create rollup.config.js in the project root directory
import babel from "rollup-plugin-babel";
export default {
input: "./src/index.js",
output: {
file: "./lib/index.js",
format: "cjs",
name: "bundle"
},
plugins: [
babel({
exclude: "node_modules/**"
})
]
};
Lastly, update prepublish in package.json
{
...
"scripts": {
"prepublish": "rollup -c"
},
...
}
Now you can run npm publish, and before the package is published to npm, you will see that lib/index.js has been generated, which is transpiled to es5:
'use strict';
var NewOneWithParameters = function NewOneWithParameters(a, b) {
console.log(a + b); // 30
};
NewOneWithParameters(10, 20);
Note: by the way, you no longer need #babel/cli if you are using the Rollup bundler. You can safely uninstall it:
npm uninstall #babel/cli
If you want to see this in action in a very simple small open source Node module then take a look at nth-day (which I started - also other contributors). Look in the package.json file and at the prepublish step which will lead you to where and how to do this. If you clone that module you can run it locally and use it as a template for yous.
Node.js 13.2.0+ supports ESM without the experimental flag and there're a few options to publish hybrid (ESM and CommonJS) NPM packages (depending on the level of backward compatibility needed): https://2ality.com/2019/10/hybrid-npm-packages.html
I recommend going the full backward compatibility way to make the usage of your package easier. This could look as follows:
The hybrid package has the following files:
mypkg/
package.json
esm/
entry.js
commonjs/
package.json
entry.js
mypkg/package.json
{
"type": "module",
"main": "./commonjs/entry.js",
"exports": {
"./esm": "./esm/entry.js"
},
"module": "./esm/entry.js",
···
}
mypkg/commonjs/package.json
{
"type": "commonjs"
}
Importing from CommonJS:
const {x} = require('mypkg');
Importing from ESM:
import {x} from 'mypkg/esm';
We did an investigation into ESM support in 05.2019 and found that a lot of libraries were lacking support (hence the recommendation for backward compatibility):
esm package's support doesn't align with Node's which causes issues
"Builtin require cannot sideload .mjs files." https://github.com/standard-things/esm#loading, https://github.com/standard-things/esm/issues/498#issuecomment-403496745
"The .mjs file extension should not be the thing developers reach for if they want interop or ease of use. It's available since it's in --experimental-modules but since it's not fully baked I can't commit to any enhancements to it." https://github.com/standard-things/esm/issues/498#issuecomment-403655466
mocha doesn't have native support for .mjs files
Update 2020-01-13: Mocha released experimental support in mocha#7.0.0-esm1
Many high-profile projects had issues with .mjs files:
create-react-app
react-apollo
graphql-js
inferno
The main key in package.json decides the entry point to the package once it's published. So you can put your Babel's output wherever you want and just have to mention the right path in main key.
"main": "./lib/index.js",
Here's a well written article on how to publish an npm package
https://codeburst.io/publish-your-own-npm-package-ff918698d450
Here's a sample repo you can use for reference
https://github.com/flexdinesh/npm-module-boilerplate
The two criteria of an NPM package is that it is usable with nothing more than a require( 'package' ) and does something software-ish.
If you fulfill those two requirements, you can do whatever you wish.
Even if the module is written in ES6, if the end user doesn't need to know that, I would transpile it for now to get maximum support.
However, if like koa, your module requires compatibility with users using ES6 features, then perhaps the two package solution would be a better idea.
Takeaway
Only publish as much code as you need to make require( 'your-package' ) work.
Unless the between ES5 & 6 matters to the user, only publish 1 package. Transpile it if you must.
A few extra notes for anyone, using own modules directly from github, not going through published modules:
The (widely used) "prepublish" hook is not doing anything for you.
Best thing one can do (if plans to rely on github repos, not published stuff):
unlist src from .npmignore (in other words: allow it). If you don't have an .npmignore, remember: A copy of .gitignore will be used instead in the installed location, as ls node_modules/yourProject will show you.
make sure, babel-cli is a depenency in your module, not just a devDepenceny since you are indeed building on the consuming machine aka at the App developers computer, who is using your module
do the build thing, in the install hook i.e.:
"install": "babel src -d lib -s"
(no added value in trying anything "preinstall", i.e. babel-cli might be missing)
Deppending on the anatomy of your module, this solution may not work, but if your module is contained inside a single file, and has no dependencies (does not make use of import), using the following pattern you can release your code as it is, and will be able to be imported with import (Browser ES6 Modules) and require (Node CommonJS Modules)
As a bonus, it will be suittable to be imported using a SCRIPT HTML Element.
main.js :
(function(){
'use strict';
const myModule = {
helloWorld : function(){ console.log('Hello World!' )}
};
// if running in NODE export module using NODEJS syntax
if(typeof module !== 'undefined') module.exports = myModule ;
// if running in Browser, set as a global variable.
else window.myModule = myModule ;
})()
my-module.js :
// import main.js (it will declare your Object in the global scope)
import './main.js';
// get a copy of your module object reference
let _myModule = window.myModule;
// delete the the reference from the global object
delete window.myModule;
// export it!
export {_myModule as myModule};
package.json :`
{
"name" : "my-module", // set module name
"main": "main.js", // set entry point
/* ...other package.json stuff here */
}
To use your module, you can now use the regular syntax ...
When imported in NODE ...
let myModule = require('my-module');
myModule.helloWorld();
// outputs 'Hello World!'
When imported in BROWSER ...
import {myModule} from './my-module.js';
myModule.helloWorld();
// outputs 'Hello World!'
Or even when included using an HTML Script Element...
<script src="./main.js"></script>
<script>
myModule.helloWorld();
// outputs 'Hello World!'
</script>
I intend to use a certain feature of angular-datatables, namely: creating filter input fields below individual columns. A demo.
This feature is available only in the dev version of the package.
I set "angular-datatables": "dev" version in my bower.json "dependencies" object, and issued:
$ bower install --save
bower not-cached git://github.com/l-lin/angular-datatables.git#dev
bower resolve git://github.com/l-lin/angular-datatables.git#dev
bower checkout angular-datatables#dev
bower resolved git://github.com/l-lin/angular-datatables.git#3c05e6a2f9
bower install angular-datatables#3c05e6a2f9
angular-datatables#3c05e6a2f9 bower_components/angular-datatables
├── angular#1.2.26
├── datatables#1.10.2
└── jquery#2.1.1
The contents of bower_components/angular-datatables ended up like this.
Next, I tried clearing my browser cache. Repeated the step above, still the version of angular-datatables remains to be 0.2.0.
I also tried issuing bower cache clean, followed by a bower install --save, but in vain.
$ bower info angular-datatables tells me that the following versions are available:
bower angular-datatables#* cached git://github.com/l-lin/angular-datatables.git#0.2.0
bower angular-datatables#* validate 0.2.0 against git://github.com/l-lin/angular-datatables.git#*
{
name: 'angular-datatables',
version: '0.2.0',
author: 'l-lin',
main: 'dist/angular-datatables.js',
ignore: [
'.bowerrc',
'.editorconfig',
'.git*',
'.jshintrc',
'Gruntfile.js',
'test',
'node_modules',
'src',
'.travis.yml',
'vendor',
'data.json',
'data1.json',
'demo',
'favicon.png',
'index.html',
'README.md',
'server',
'styles',
'_config.yml',
'grunt',
'images',
'package.json'
],
dependencies: {
angular: '>=1.2.6',
jquery: '>=1.11.0',
datatables: '>=1.9.4'
},
devDependencies: {
'angular-mocks': '1.2.6',
bootstrap: '3.0.1',
'angular-bootstrap': '0.10.0'
},
homepage: 'https://github.com/l-lin/angular-datatables'
}
Available versions:
- 0.2.0
- 0.1.1
- 0.1.0
- 0.0.3
- 0.0.2
- 0.0.1
Next, I reverted back to v0.2.0, and then used the install command with a #dev suffix.
$ bower install angular-datatables#dev --save
bower angular-datatables#dev not-cached git://github.com/l-lin/angular- datatables.git#dev
bower angular-datatables#dev resolve git://github.com/l-lin/angular-datatables.git#dev
bower angular-datatables#0.2.0 cached git://github.com/l-lin/angular-datatables.git#0.2.0
bower angular-datatables#0.2.0 validate 0.2.0 against git://github.com/l-lin/angular-datatables.git#0.2.0
bower angular-datatables#dev checkout dev
bower angular-datatables#dev resolved git://github.com/l-lin/angular-datatables.git#83ce3847da
Unable to find a suitable version for angular-datatables, please choose one:
1) angular-datatables#dev which resolved to 83ce3847da
2) angular-datatables#0.2.0 which resolved to 0.2.0 and is required by zap-adm-ang
Prefix the choice with ! to persist it to bower.json
? Answer:: 1
This updated my bower.json file, to "angular-datatables": "dev", however when I open the angular-datatables.js file in the bower_components/angular-datatables/dist/ directory, the version still remains 0.2.0. The problem persists.
Here is my discussion of the issue with the angular-datatables package maintainer (in case I missed out on some details).
One possible solution that the package maintainer suggested is to use the following (upcoming) version of angular-datatables:
/*!
* angular-datatables - v0.2.1
* https://github.com/l-lin/angular-datatables
* License: MIT
*/
which is currently available here and should soon be released.
Did the trick for me. The feature is available.
I am still really curious as to why the above-described process of #dev version installation didn't work for me.
In my project I would like to use jquery-mobile via bower.
Before I can use it I have to run npm install and grunt subsequently inside of bower_components/jquery-mobile before I can use the minified .js and .css files.
This is quite tedious and if I had to do this for every library that I use, I guess I would fallback to just downlading the files and add them to my project.
So is there a more elegant way to get to those "final" files via bower dependency?
My bower.json
"dependencies": {
...
"jquery-mobile": "latest",
}
The fact of having to run npm/grunt process (or not) is up to each author. In the case of jQuery Mobile, probably some external user has registered it without noticing that it needs to run Grunt tasks; Bower unfortunately allows everyone to register packages (is that bad or good? :S).
Also, there may exist some Grunt task to install bower dependencies and run their Grunt tasks aswell; if there aren't, it's not too complicated to create one.
Anyway, as it seems that you're in a "hurry" for those final, compiled files, there is jquery-mobile-bower, which has been created and registered into Bower a few hours ago.
bower install jquery-mobile-bower
Let's just hope that this gets maintained and up-to-date.
Just so you're aware, there is an official jQuery mobile Bower package available. It can be installed via:
bower install jquery-mobile
Its GitHub endpoint can be found here.
I'm not sure if my solution is optimal, but I removed jquery-mobile from bower.json and I'm installing and building it with Grunt, using grunt-contrib-clean, grunt-git and grunt-run plugins. I came up with this, because I don't want to use jquery-mobile-bower, because it's an unofficial repo.
Here's an example Gruntfile.js:
module.exports = function (grunt) {
grunt.initConfig({
clean: {
jquerymobile: 'bower_components/jquery-mobile'
},
gitclone: {
jquerymobile: {
options: {
repository: 'https://github.com/jquery/jquery-mobile.git',
branch: 'master',
directory: 'bower_components/jquery-mobile'
}
}
},
run: {
options: {
cwd: "bower_components/jquery-mobile"
},
jquerymobile_npm_install: {
cmd: "npm",
args: [
'install'
]
},
jquerymobile_grunt: {
cmd: "grunt"
}
}
});
grunt.loadNpmTasks('grunt-contrib-clean');
grunt.loadNpmTasks('grunt-git');
grunt.loadNpmTasks('grunt-run');
grunt.registerTask('default', [
'clean',
'gitclone',
'run'
]);
};
More details can be found here https://github.com/jquery/jquery-mobile/issues/7554