I have an npm project which is used solely for UI components and I have another one that is used for everything else. Since these two will be running in the same environment, I want to make sure they use the exact same version of runtime dependencies.
Here's an example. The project structure looks like:
root
- UI Component Project
- Main Project
The "Main Project" has a package.json with all the necessary dependencies it needs. What I want to do is to let "UI Component Project" use the exact same versions of the dependencies used in "Main Project", but only those that are also used in "UI Component Project".
For example, "Main Project" may have several dependencies such as TypeScript, React, and several others. "UI Component Project" also has its own set of runtime dependencies but they also use TypeScript and React. In this case, I want to make sure "UI Component Project" installs its own dependencies plus TypeScript and React with the same exact version used in "Main Project".
Does npm natively support something like this? I'm looking for something automatic to achieve this without manually trying to sync the dependencies in two projects.
I found that tools like lernacan help me do this.
Related
We got couple of different projects that are using main dependencies like React and TypeScript packages. Each of those projects(maintained by different dev team) is using diferent version of React and TypeScript - question here:
Is there any clever way to share/inherit/force to use specific version of main dependencies across all those projects? i.e.:
Yes, this is definitely possible. Simplest way is to create an npm module with the required common dependencies in a package.json file and publish this into your repo. Then in the projects, require that published npm module as a dependency. The projects can than further require other dependencies and override any from the parent if needed.
When I run npm install #aspnet/signalr in my project directory, over 20 modules are installed into node_modules. However, in the actuall project, for example on a webpage, only signalr.js needs to be referenced. How does signalr.js reference its dependencies?
One additional example I find confusing is that when bundling, only signalr.js needs to be put into bundleconfig.json for SignalR to work in the project. Are the other dependencies actually needed?
When webpack bundles the node_modules my project needs, do I still need dependencies or could I list everything to devDependencies?
I have created a react component library and have published it to npm. The only peerDependencies I've listed are react and react-dom, because, well, you'll need them when using my library. At first I set up my project like I normally would, stuff like babel, eslint, css-loader listed in the devDependencies, and stuff I actually use in my code, like prop-types, classnames, react-slick, listed as dependencies.
I then use webpack with babel to create one main.js with the module imports included
When someone on my team tries to use my library npm will give some errors 'Peer dependencies unmet' with stuff like webpack, eslint & #babel/core. So I'm guessing these are some peer dependencies from my dependencies? (that's a little side question)
That got me thinking, do I even need dependencies at all? Since webpack bundles everything and I only use my main.js, shouldn't everything be a devDependency?
Dependencies are those that your project needs to run, like a library that provides functions that you call from your code.
Dev dependencies are dependencies you only need during development or releasing, like compilers that take your code and compile it into javascript, test frameworks or documentation generators.
Working on a larger typescript project we decided to move the code to a monorepo with yarn workspaces.
We use webpack to build and bundle and everything works well (especially the linking between local modules/packages).
Since yarn workspaces will store most of the node_modules in the mono repo's root folder, the IDE (IntelliJ as well as VSCode) have problems resolving the imports to any node_modules when coding inside a "inner" project (so called "package" of a monorepo).
The strange thing is that imports are not known but on the other hand most of the time you can navigate to the correct source / definition within the IDEs for the same import if you write it down manually.
We have tried to tell IntelliJ to look into another folder for node_modules, but still not satisfying.
Please share your experience with yarn workspaces / monorepo (e.g. lerna) and how you develop the code living in these monorepos.
Which IDE do you use?
Did you add any special configurations to the IDE and/or package.json, tsconfig.json?
https://github.com/Izhaki/mono.ts
It uses yarn workspaces and marry well with VSCode. I hope the README is clear enough.
Basically, use two (parallel) typescript configuration trees:
Pre-build - uses aliases (for VSCode, tests, webpack, etc).
Build - uses typescript 3 project references for publishing essentially.
IDEA doesn't provide any support for Yarn workspaces; if you miss it, please follow WEB-29250 and linked tickets for updates.
You can try adding path mappings to your tsconfig.json - see https://intellij-support.jetbrains.com/hc/en-us/community/posts/207656825/comments/115000529564
Upodate as of 2018.1.1 IntelliJ now supports yarn workspaces so if you use this there should not be a problem.
https://blog.jetbrains.com/webstorm/2018/04/webstorm-2018-1-1/
Please share your experience with yarn workspaces / monorepo (e.g. lerna) and how you develop the code living in these monorepos.
Which IDE do you use?
Since you are asking. I basically ran into the same issues as you did. One solution I was looking into was disable hoisting node modules as described here. Unfortunately it seems it is not yet in the stable release.
What I ended up was ditiching workspaces for now until they fix either the IDE or release the nohoist option. Instead I am using lerna for now. It is less convenient but it does not hoist so that both the build tools and the IDE are satisfied.
Oh, I am also using IntelliJ (ultimate)
I have 2 completely separate projects where one depends on the other. I've very recently mavenized the main project but can mavenise the dependency if absolutely necessary.
Originally these were Netbeans projects, with the main project having several modules. What I liked is that I could declare the dependency as a dependent project. This allowed me to use the most recent code as it changes a lot (the project is in its infancy). NetBeans would put the dependent project on the classpath when running, and build a jar in the /dist directory when doing a clean and build.
Now that the main project is in maven, I can't do this anymore. The only alternative I've found was to manually copy it into the project repository, but that removes a lot of automation and ease of use. Every time I wanted to test a change I would have to rebuild the dependency, move it to the buried project repository folder, rename it appropiatly, switch back to NetBeans, then run. This is vs clicking run and everything being done automatically.
Maybe I'm just lazy, but is there an easy way to do this?
I have 2 completely separate projects where one depends on the other. I've very recently mavenized the main project but can mavenize the dependency if absolutely necessary.
Mavenizing the dependent project would help a lot. Like Eclipse or IntelliJ, NetBeans supports something Eclipse calls Workspace dependency resolution: if a project A depends on a project B and you open both of them in your IDE, A can be configured to depend on B sources instead of B jar (and any change would become immediately visible).
mavenizing the depedency project is the best option.
Alternatively you might get away with using a system scope dependency which points to the dependency project's dist/ folder jar artifact.