Relative paths in package.json? - json

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')

Related

Webpack 3.5.5 debugging in chrome developer tools shows two source files. One under webpack:// and other under webpack-internal://

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.

immutable flow fails . live test on travis

Hello this questions is having a minimal working example of what Im trying to build.
Im having troubles to run flow-type checker on just simple JS file. Here is how the file looks like
// #flow
import type { Map } from 'immutable';
And I even build a minimal working (NOT working) example with travis running it.
Here is the repository. It's very simple and only has flow and immutable-js dependencies.
https://github.com/RusAlex/immutable-flow
and here is the failed Travis-ci build
https://travis-ci.org/RusAlex/immutable-flow/builds/243260858
Flow reads the package.json to find out about imports, but since you moved your .flowconfig inside your src/ folder, it no longer can. If you include the package.json by adding ../package.json to your [include] you get an interesting error:
src/flow.js:2
2: import { Map } from 'immutable';
^^^^^^^^^^^ This modules resolves to "<<PROJECT_ROOT>>/../node_modules/immutable/package.json", which is outside both your root directory and all of the entries in the [include] section of your .flowconfig. You should either add this directory to the [include] section of your .flowconfig, move your .flowconfig file higher in the project directory tree, or move this package under your Flow root directory.
Finally, adding ../node_modules/immutable/ will help flow resolve everything again.
Alternatively, you could just add .flowconfig to the actual project root. It makes things simpler and seems to be the intended default.

What's resolutions and overrides in a `bower.json` file?

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.

How do I make Jekyll exclude my config.rb for SASS?

In Jeky'll's _config.yml file I have the following at the bottom: exclude: README.md, css/config.rb
It excludes the README fine, but not the config.rb file. What am I doing wrong?
This is a problematic feature of Jekyll for quite some time.
Just to be sure: what version of Jekyll are you using? The latest ones enforce correct YAML handling, so you should be using the array syntax (exclude: [README.md, config.rb]).
It's possible with the current implementation to use glob syntax and exclude a whole directory (or tree of directories or whatever), but I couldn't find an issue or documentation on how to exclude a specific file in the filesystem.
In any case, you can exclude config.rb. I assume you don't have another one in your site, and even if you have, you probably don't want it to be on _site. This is bad overall, but works. Your exclude rule would be exclude: [README.md, config.rb].

In Node.js, how can a module get data from an application's package.json?

I have a module. Inside it, I'd like to access data from my parent application's package.json file. What's the best practice way to do that?
I've done this the janky way by going up 2 levels and requiring the file (or using the nconf configuration loader).
var appdir = path.resolve(__dirname, '../../');
nconf.file('app', path.join(appdir, 'package.json'));
But that seems like it could break easily.
Also I heard about pkginfo, it will automatically grab info from my own module's package.json, but I'm looking to get data from the parent application's.
Thanks for any help!
EDIT: I suppose another way of asking is, how can I get the application's path (instead of the module path) ?
You can use
require.main.require './package'
But it'll work only if your parent application's file is in a root of it's directory.
You can also wrap it into try ... catch and add ../ to path till you find package.json.
You can read more about accessing main module here http://nodejs.org/api/modules.html#modules_accessing_the_main_module
Adding to pcru's approach, this should work:
function loadMainPackageJSON(attempts) {
attempts = attempts || 1;
if (attempts > 5) {
throw new Error('Can\'t resolve main package.json file');
}
var mainPath = attempts === 1 ? './' : Array(attempts).join("../");
try {
return require.main.require(mainPath + 'package.json');
} catch (e) {
return loadMainPackageJSON(attempts + 1);
}
}
var packageJSON = loadMainPackageJSON();
Keep in mind that this will get you the main module, which something you think is what you want , but if you're building a command line tool like I was, what you really want is to get the package.json exactly two folders above where you were installed if your tool is meant to be installed locally and called with npm run-script
As mentioned in Determine project root from a running node.js application , one of the easiest ways to get to your application path is using process.cwd(), provided you have the discipline to always start your main js program from the same directory. i.e. node app/main.js and cd app && node main.js will give different results.
Another way could be to recursively follow the references to module.parent, then read out module.filename when module.parent is undefined. This also presupposes some knowledge about your app. It won't work if the location of the main script relative to the package.json could vary. I.e. you must know if the main script is in the root of the app directory, or maybe in some sort of 'bin', 'app', or 'lib' dir. However, once you find the top-level module, you could try to locate the closest package.json using the same algorithm pkginfo uses to find the package.json for the current file.