In my front-end code, I use require() to pull in libraries which, in turn, depend on different versions of Underscore.js. As a result, when I use browserify to bundle everything together, the output contains multiple copies of Underscore. Is there a way to tell browserify that require('underscore') should always import a particular file?
As a demonstration of the problem, imagine I have the following dependencies:
// package.json
"dependencies": {
// Depends on underscore 1.7.0
"backbone": "^1.1.2",
// Depends on underscore 1.6.0
"backbone.marionette": "^2.3.0"
}
In main.js I use both libraries:
// main.js
var Backbone = require('backbone');
var Marionette = require('backbone.marionette');
console.log("Hello, world!");
When I create a bundle, multiple versions of Underscore are included:
PS> browserify main.js -o out.js
PS> findstr _.VERSION out.js
_.VERSION = '1.7.0';
_.VERSION = '1.6.0';
(I created a GitHub repository with a more complete example. Clone it and run npm install && npm test to see it in action)
I tried adding a browser section to my package.json like the following, but it didn't seem to have any effect:
// package.json
"browser": {
"underscore": "./node_modules/underscore/underscore.js"
}
I understand why npm installs duplicate dependencies (and it makes sense to do it this way for server-side code) but what's the correct way to deal with this when using browserify?
There is a duplicate detection in Browserify that should avoid loading the same version more than once. However, if your node_modules tree contains multiple copies of the same module, this detection might (should?) fail.
The solution that I'm using is to dedupe the package structure with npm:
npm dedupe
This will only leave unavoidable dupes in your dependency tree and it will log a warning about those dupes so that you can double check.
Related
I have an error when I want to run Jest because of moduleNameMapper settings.
I tried several methods, but nothing changes.
To reproduce:
clone the repo: https://github.com/zoztorun/reproduce-webpack-alias-error
npm install
npm run test
Since you're using Vue CLI, you should use #vue/cli-plugin-unit-jest, which can be added to your Vue CLI project with this command:
vue add unit-jest
This will also add a <rootDir>/test directory with a sample test, but that doesn't fit your project's test file pattern, which places *.spec.js adjacent to the source files.
To adapt the result to your project:
Delete <rootDir>/test (as it would be unused, and because it points to a nonexistent HelloWorld.vue)
Edit the jest config in package.json to be:
{
"jest": {
"preset": "#vue/cli-plugin-unit-jest",
"testMatch": [
"**/src/**/*.spec.[jt]s?(x)"
]
}
}
Delete your test NPM script, since #vue/cli-plugin-unit-jest automatically adds its own test:unit script, which must be used instead (i.e., use npm run test:unit).
I am in the process of switching my monorepo (back) from yarn (with workspaces) to lerna/npm, because yarn is too slow and unstable. However, I made an surprising discovery. With the following trivial package.json:
{
"devDependencies": { "lerna": "^2.11.0" },
"dependencies": { "typescript": "^2.9.1" }
}
and an empty lerna.json (in other words, no packages at all), then when I run
$ lerna bootstrap
it does not install anything at all in any top-level node_modules directory. And if for some reason I have a node_modules directory with no .bin subdirectory, then lerna bootstrap fails to create or populate the .bin subdirectory.
Is lerna not designed to actually specify top-level packages which are to be installed (along with their binaries in .bin)? I do notice that if I try lerna add on a lerna monorepo with no packages, it complains that "lerna WARN No packages found in scope where tslint can be added."
I could not find anything related to this in the documentation. With yarn/workspaces, I was using the ability to install global (top-level) versions of things like TypeScript for use in my build scripts while maintaining control over the version installed.
From the Lerna docs:
You can add the root as a managed location (in the packages array of lerna.json) - if that's something you need. This would cause lerna to link root's dependencies to your packages' directories, run postinstall script along with the others, etc.
I see --save-dev mentioned in Gulp tutorials and from what I see, it adds npm functionality to a project's dependency.
But what does that mean exactly? Is that significant when the project gets moved from one machine to another?
Thank you for any clarification of --save-dev importance with Gulp.
In a npm package there 2 types of dependencies: the production ones and the development ones.
{
"dependencies": {
// .. a list of production dependencies
// i.e. angular or express
},
"devDependencies": {
// .. a list of dependencies strictly needed only in development mode
// i.e. gulp or grunt
}
}
You need the former to make the application run in production. The latter are used when in development mode, so everything around the build system, minification, etc...
Gulp, as a building system, is more a devDependency by nature, than a production dependency. This is why you often find in Gulp/Gulp plugins tutorials things are:
$ npm install --save-dev gulp
That --save-dev flag will put the installed dependency you're asking in the devDependencies bucket while using --save sets the dependency in the dependencies (production) one.
I have a weird set of "local" npm modules that use TypeScript and depend on each other similar to:
A -> B, C
B -> C
C -> D
I need to run npm install and get all of my TypeScript compiled in order or it won't be able to find things properly. I'm under the impression I should use prepublish scripts to handle the TypeScript compile but it doesn't seem to cascade the prepublish request for local dependencies.
How am I supposed to set up a bunch of local modules with prepublish scripts such that they all get resolved appropriately when running npm install?
Another way to word what I am asking: How do I maintain multiple, local node modules and modify them at the same time? The modules have varying dependencies on each other and it is extremely inconvenient to modify them in isolation.
TypeScript compile but it doesn't seem to cascade the prepublish request for local dependencies.
Indeed prepublish only runs install for dependencies. Your dependencies should already be built (with prepublish) before putting them on NPM and installing them.
I figured out how to do what I needed. After updating to npm 3.3.9 and TypeScript 1.6, I was able to use a postinstall script to build things on the fly. The prototype lives here: https://github.com/MrHen/TypeScriptNpm
But the important pieces are:
// In the module's package.json
"scripts": {
"build": "gulp npmbuild",
"postinstall": "npm run build"
},
And:
// In the server's package.json
"dependencies": {
"hen-doodad": "file:../modules/hen-doodad",
"hen-widget": "file:../modules/hen-widget"
}
And:
// In the gulpfile
gulp.task('npmbuild', function() {
gulp_util.log('Detecting appropriate starting directory...', process.env.INIT_CWD);
var out = process.env.INIT_CWD + '/app';
var build = [process.env.INIT_CWD + '/**/*.ts', 'typings/tsd.d.ts', '!' + process.env.INIT_CWD + '/node_modules/**/*'];
var typings = 'typings/tsd.d.ts';
// ... do typescript build using above paths
Feels like a bit of a hack but this worked more consistently than prepublish. To run the whole thing, do an npm install inside of the server folder.
The gulp task is optional. Presumably you could use tsc directly.
It should be noted that this is most certainly not how you should be packaging up npm modules. The reason I had to do this involved details from a pre-existing build system.
Pitfalls from doing it this way:
Does not fit the standard publishing patterns used by npm.
The built files only ever live inside of the server's node_modules which can be awkward depending on what else you do with them.
Running npm install twice will not grab latest changes. You need to either remove the installed modules or update the version number on the module.
Each module gets its own TypeScript build instead of building en masse. If you can just build everything all at once you should do that instead.
Requires TypeScript 1.6 or greater due to how they auto-detect typings files included inside of node_modules.
Assuming that you are using TypeScript 1.6+ which support node module resolution. As you are trying to keep all modules synced, I guess your project is just starting.
I think symlinks would do the job, but if you have more concerns, please let me know.
More specifically, you may either create symlinks manually or take the advantages of npm link.
cd /path-of-a-module
npm link # this will create a link as global module
cd /path-of-your-app
npm link your-module-name
Then you may just maintain these modules happily.
As for dependencies configuration in your package.json file, it could be a git repository. But you could probably left the compiled *.js and *.d.ts files there and everything would just work.
Given the following directory structure:
my-project
|
|-- node_modules
|
|-- react
|-- module-x
|
|--node_modules
|
|--react
You can see both my-project and module-x require React. I have the same problem as described on this question, but the suggestion is to remove react from the package.json dependencies. I do that and it works fine, as long as no node_modules are installed in module-x, because Webpack will use React from my-project. But if I'm in the process of developing module-x and the node_modules are installed, Webpack uses React from both my-project and module-x.
Is there a way I could have Webpack make sure only one instance of React is used, even though it's required on two separate levels?
I know I could keep module-x in a separate directory when developing, but it seems like I'd have to publish it and then install it in my-project to test it, and that's not very efficient. I thought about npm link, but had no luck with it since it still has node_modules installed in module-x.
This here sounds a lot like the same challenge I'm having, but it doesn't seem like npm dedupe or Webpack's dedupe option would work. I'm probably not understanding some important detail.
This issue usually arises when using npm link. A linked module will resolve its dependencies in its own module tree, which is different from the one of the module that required it. As such, the npm link command installs peerDependencies as well as dependencies.
You can use resolve.alias to force require('react') to resolve to your local version of React.
resolve: {
alias: {
react: path.resolve('./node_modules/react'),
},
},
If you don’t want to (or can’t) modify the project configuration, there is a more straightforward solution: just npm link React itself back to your project:
# link the component
cd my-app
npm link ../my-react-component
# link its copy of React back to the app's React
cd ../my-react-component
npm link ../my-app/node_modules/react
Just in case it's useful for others, the solutions suggested above didn't work for me, I had to perform the following steps to solve it:
In the library:
Setup the libraries that are generating issues as peerDependencies in the package.json instead of dependencies or devDependencies, e.g. in my case react:
"peerDependencies": {
"react": "^16.8.6",
...
}
run npm install
build the library (in my case, with a rollup -c npm script
In my main app:
change the version of my library to point to my local project with a relative path in package.json, e.g.
"dependencies": {
"my-library": "file:../../libraries/my-library",
...
}
Add resolve.symlinks = false to my main app's webpack configuration
Add --preserve-symlinks-main and --preserve-symlinks to my package.json start script, e.g:
"scripts": {
"build": "set WEBPACK_CONFIG_FILE=all&& webpack",
"start": "set WEBPACK_CONFIG_FILE=all&& webpack && node --preserve-symlinks-main --preserve-symlinks dist/server.js",
}
run npm install
run npm run start
In the same vein as the accepted answer here's how you can achieve the desired outcome with Craco:
const path = require('path')
module.exports = {
webpack: {
configure: config => {
config = {
...config,
resolve: {
...config.resolve,
alias: {
...config.resolve.alias,
'react': path.resolve('./node_modules/react'),
},
},
}
// console.log(config)
return config
},
},
}
It's important to note you can't just pass resolve as a key, you have to do your own deep merge using the configure callback.