In a bower.json file, what are the resolution and overrides properties used for?
{
"name": "name",
"dependencies": {
"angular": "~1.4.8",
...
"jquery": "2.2.4"
},
"overrides": {
"ionic": {
"main": [
"release/js/ionic.js",
"release/js/ionic-angular.js"
]
}
},
"resolutions": {
"angular-ui-router": "~0.2.15",
"angular": "~1.5.3"
}
}
Resolution
The resolution section appears when you need to resolve dependency versions (after bower install) when conflicts occur. It's for making a decision regarding which concrete version of a dependency to use when the need to resolve dependency conflicts arises - bower automatically injects this decision as the "resolution" record. So the next time a conflict occurs (when updating the dependency tree, etc), the resolved version will be based on the "resolution" data in your configuration file.
Overrides
Overrides section is used to override the file(s) references when pointing to dependent library.
Task runners in most cases use the bower configuration library metadata to inject links to these libraries into a page's content. When we want to inject a bootstrap link into a page, we do not need to go into the "bower_components" folder, find the package, and investigate the file content. We can use the component metadata to find the main, injectable file reference.
The "overrides" section is used to change this data to use another file, or even a set of files, as a package's main entry point.
Multiple Bower packages can list different versions of the same library as a dependency. The resolutions section specifies which version of the library to use whenever this type of situation occurs. If not specified in bower.json, you will receive a command line prompt upon running bower install.
The overrides section makes it possible to override default paths to assets installed through Bower when using a task runner like Gulp. If you intend to move files from their default location in the bower_components folder to accommodate your build process, for example, it could prove handy in this type of setup.
We use resolutions object in your bower.json file to specify the component name & version to automatically resolve the conflict when running bower commands.
Overrides section is used to override the file(s) references when pointing to dependent library.
Related
The new Chrome 64 security update seems to have broken the htmlToImage libraries. None of the styling is correctly calculated and is rendered as if no styling was applied at all.
Does anyone know of a workaround / fix? Do I need to put my CSS on the server and allow CORS?
I just fixed this error.
Forked the lib and made a pull request. Until it gets merged, you can use the forked repo: https://github.com/kmap-io/html-to-image
by replacing the target of html-to-image in your package.json with:
"html-to-image": "git+https://github.com/kmap-io/html-to-image.git"
About the bug
Chrome is complaining (throws an error) about trying to read a property that does not exist. Firefox also complains, but they only throw a warning, instead of an error. The fix consists of replacing
if (sheet.cssRules) {
...
with
if (sheet.hasOwnProperty('cssRules')) {
...
There is no downside (i.e.: when cssRules exists on sheet - which is a stylesheet - the script iterates through the rules and adds them to document, as supposed to).
How to patch (until it gets merged).
For some reason, simply replacing the library's repo with the fork in which I committed the change doesn't work for this package. I asked the lib's author to add instructions on how to build after a pull-request, as they state in the readme pull requests and contributions are welcome. Until then, here's how to apply the fix using patch-package:
add "prepare": "patch-package" inside scripts, in your project's package.json
npm i patch-package --save-dev
In node_modules/html-to-image/lib/embedWebFonts.js, change line 7 from
try {
to
if (sheet.hasOwnProperty('cssRules')) try {
npx patch-package html-to-image
If you have a deployment script that builds your project from scratch, you'll need to apply the patches right before you call npm run build (or similar, depending on your stack):
git apply --ignore-whitespace patches/*.patch
That's about it.
When the fix will be merged, you'll need to run:
npx patch-package html-to-image --reverse
Migrated existing webpack project to use webpack 3.5.5 and its new config. Using express server instead of webpack-dev-server.
I had to setup the resolve in webpack as below.
const resolve = {
extensions : ['.js'],
modules : [
'node_modules',
'src',
'testApplication'
]
};
When i debug this webpack application using chrome developer tools I can see the 2 versions of source files.
The first one under webpack://
It is exactly matching with the source
The second one under webpack-internal://
This one is the babel compiled version of the source.
My questions are
Is there someway where I get only a first version of the file instead of both?
I thought node_modules should have been implicitly defined as a module rather than me specifying it explicitly in resolve, is there someway that I can make the build work without having the node_modules defined in resolve.
After using the same source code with webpack 3.5.5(migrated it from webpack 1.14.0) the express server start seems to have slowed node. My guess is that having specified the node_modules in modules under resolve has caused it. Any ideas?
You can configure the source maps using Webpack's devtool property. What you want is devtool: 'source-map'(source). This will only show you the original source code under webpack://. Note that there are other options that might be more appropriate for your use case.
["node_modules"] is in the default value for resolve.modules. However, if you specify resolve.modules you need to include "node_modules" in the array. (source).
It seems strange that you specify "src" and "testApplication" in resolve.modules. If you have local source files you should require them using relative paths e.g. require("./local_module"). This should work without having src in resolve.modules
Specifying node_modules in resolve.modules is not responsible for any slow down (see 2.). There are many possible reasons the slow down. E.g. maybe you are erroneously applying babel to the whole node_modules folder?
It seems to be resolved (or at least greatly improved) in Chrome 66.
There is a project split into several repositories cloned into separated folders. There is a library which is not referenced in package.json (and mustn't be) of other repositories as it is added via a build script.
How can I override WebStorm so that it does not display "Module is not installed" error for every import from that?
N.b., I need the library where it is, not in node_modules, so adding it to package.json is not a solution.
For me, this warning was displaying for all local imports. I resolved it by adding the path to the WebPack config file.
Preferences -> Languages & Frameworks -> JavaScript -> WebPack
Other than File -> Invalidate Caches / Restart, which will take some time for WS to reindex, you can use this workaround
You can disable the "Missing module dependency" inspection in the whole project either in Preferences | Editor | Inspections or by hitting Alt-Enter on the highlighted error, then arrow right - Disable inspection.
You can also create a new Scope that excludes that folder in Preferences | Appearance and Behavior | Scopes and then set the inspection's scope to it.
I solved this problem a bit differently. I added file webpack.alias-config.js in my main folder of project:
const path = require('path')
module.exports = {
resolve: {
alias: {
'#': path.join(__dirname, 'src'),
},
},
}
Next I added path to this file (webpack.alias-config.js) in: Settings -> Languages & Frameworks -> JavaScript -> Webpack:
And now I can use this alias e.g:
import MyFile from '#/components/MyFile'
In my case everything was set up correctly, but I had node_modules as exception in Settings: Editor -> File Types -> Ignore files and folders. The problem was solved after I removed it from there and waited for indexing.
For Laravel Mix users, Jetbrains products dont support the Laravel Mix config file.
Use one of these workarounds:
https://youtrack.jetbrains.com/issue/WEB-42186 (I prefer this one, because you dont need to create or edit the existing files)
Path aliases for imports in WebStorm
I've got a project where src/main/webapp/com/mycompany/frontend/page/index.js depends on target/webjars/log4javascript/1.4.10/log4javascript.js.
I've added package.json alongside index.js with the following contents:
{
"browser":
{
"log4javascript": "../../../../../../../target/webjars/log4javascript/1.4.10/log4javascript.js"
}
}
I've got many other dependencies in the target directory. Is there a way for me to avoid repeating ../../../../../../../target/ for every dependency?
One option is to put the directory that contains your local modules, or a symlink to it, in node_modules, such as node_modules/app and then reference your requires as app/..., e.g. I believe this would work
{
"browser":
{
"log4javascript": "app/target/webjars/log4javascript/1.4.10/log4javascript.js"
}
}
Or you could structure it however you want, e.g. node_modules/log4javascript (which, if you have symlinks, could point to /whatever/target/webjars/log4javascript).
This makes it so that require() will find it in the same fashion as npm modules, without publishing it to npm. The main drawback to this is that it breaks the ability to programatically configure transforms, e.g. with browserify('app/entry').transform(whatever), app/entry and other files in the dependency graph that are under node_modules will not have the transform applied to them.
Check out the section Using Non-Relative Paths in this article.
You can use grunt-browserify's aliasMapping option to specify the root of your app:
aliasMappings: [{
cwd: 'src',
dest: 'myApp',
src: ['**/*.js']
}]
and then you can directly refer to everything from the root path, without having to ever use any dreaded ../'s:
require("myApp/target/webjars/log4javascript/1.4.10/log4javascript.js")
Of course, this doesn't resolve the problem that it's still a very long path.
The article's next paragraph makes a very good point: if you're calling things way over at the other end of your application like that, it's a good sign that things may not be correctly architected.
Can you split the functionality into smaller modules? Perhaps make log4javascript its own module?
Add to my answer, from discussion below:
If log4javascript is in your package.json file as a browser (non-NPM) module, you should just be able to require it with require('log4javascript')
I'm trying to compile some JS libraries that we have with lein-cljsbuild to integrate them in our ClojureScript code base. First I added some goog.provide in top of each file, and the files are hierarchically organised in a directory tree according to their namespace (like in Java). That is namespace a.b.c is in src-js/libs/a/b/c.js
I have put the JS files in the root directory of the projects in src-js/libs, and I have the following :compiler options for lein-cljsbuild:
{:id "prod",
:source-paths ["src-cljs" "src-js"]
:compiler
{:pretty-print false,
:libs ["libs/"]
:output-to "resources/public/js/compiled-app.js",
:optimizations :simple}}
None of the JS files get compiled into the compiled-app file. What's wrong?
I also tried to put them in resources/closure-js/libs without success.
I'm using lein-cljsbuild 0.3.0.
First, unlike what is suggested in some texts, you do not need to include your private closure library locations in any classpath configuration statement in your project.clj. So unless the "src/js" directory included in your "source-paths:" statement is for some other purpose, you can remove it.
Second, the only thing to add to your project.clj, for the sake of bringing in your private closure code, is the "libs:" reference you have made; BUT unlike what you have entered, that reference must be to a specific *.js file (or files) and not merely a directory. So if the library you want to used is in a file named test.js and that resides in the /src/js directory, your libs: entry would be: "src/js/test.js". See the cljs-build release notes if you want to use that plugin's default :libs directory option.
Third, (and it looks like you know this already, but this is what tripped me up) if you are using a browser-backed REPL (repl-listen option of cljsbuild), you still will not be able to load/reference/use your private library assets from that REPL until you include a :require statement somewhere in the source for your compiled-app.js (e.g. "(ns testing (:require [myprivatelib]))" ), THEN you must re-compile (lein cljsbuild once) and reload your browser page with a link to compiled-app.js. This brings in that code base. Otherwise, your browser REPL will just keep insisting that the namespace provided in your closure library is not defined.
I hope this helps.