When I run yarn init one of the questions is question private. I searched everywhere but couldn't find an explaination for that. What does it mean private in this context?
yarn init is meant to assist you in the process of creating a package.json for a new project.
private means adding a private: true field in the autogenerated package.json, which will instruct npm to refuse publishing the package to the public NPM registry on npm publish.
Related
I am using Yarn's Workspaces feature to manage a monorepo. Some of the individual workspaces have their own dependencies defined in their own package.json, however I also have some shared dependencies (some are for testing the whole repo, some are used by all the workspaces). How do I declare these the correct way?
If I try to add them to the root package.json, Yarn gives me a warning. But adding the same dependency to all n workspaces (there are a lot and it's liable to grow) seems tedious and hard to maintain when upgrading dependencies.
Is the right thing to do to add the shared dependency (say, typescript, or jest or serverless) to every single individual workspace?
Using Yarn 1/classic.
I found also Yarn Workspaces: How and where should I install my dependencies? but it's unanswered
Yarn workspaces shared dependencies talks about using peer dependencies but the user is experiencing trouble
After a half-day search and trying, I found multiple ways to manage shared dependencies
1. Sync dependency version with syncpack
https://github.com/JamieMason/syncpack/
Given the fact that yarn workspaces will share the dependencies if their versions are the same (see https://classic.yarnpkg.com/lang/en/docs/workspaces/), all we have to do is to keep the dependency versions in sync to make dependencies sharing, which is exactly what syncpack does.
I found this is the least harmful way to make sharing dependencies works, while other methods require some degree of twisting package.json.
2. Use peer dependencies
For each package, set sharing dependencies as peerDependencies with version “*”, and set root workspace set the real dependencies. For example:
# ./package.json
{
...
"workspaces": ["packages/*"],
"dependencies": [
"some-lib": "^1.0.0",
]
}
# ./packages/pkg-a/package.json
{
...
"peerDependencies": [
"some-lib": "*",
]
}
and yarn install at workspace root.
3. Share script (require yarn v2)
See https://yarnpkg.com/getting-started/qa#how-to-share-scripts-between-workspaces
Miscellaneous
yarn provides workspace cli to add/remove package, see https://classic.yarnpkg.com/lang/en/docs/cli/workspace/
yarn workspace awesome-package add react react-dom --dev
yarn workspace web-project remove some-package
I am using yarn 1.22.10.
I am developing a project which uses a yarn-linked dependency named module-one which in turn yarn-links to a dependency named module-two.
Is yarn able to follow these yarn link chains?
According to yarn documentation ,
a package can be linked into another project.
So if module-one is a package which is developed using module-two and then module-one is further called into another project using yarn link, technically it should work provided module-one is a package containing its own package.json.
But I would like to suggest not to use yarn link in a chain like wise because during production if dependency module-two modifies/updates/returns error and these changes are not translated to module-one; then the project might suffer and will return with unexpected errors/exceptions which will be pain to track and rectify.
Therefore I would like to suggest that you must install the module-two as dependency in module-one and then yarn link module-one to your project.
Here is my problem, I constructed a dockerfile launching yarn install from a folder where a package.json and yarn.lock are present (they have been taken from the project I have to setup yarn dependencies for, this project is inside a deconnected server).
Then, I run bash into container image and uploaded the created folder node_modules, and put it into the deconnected server, where project is present, at root folder project.
But then, when I launched yarn start from root folder, it says that it cannot find rescripts despite of the fact that folder #rescripts is present into node_modules.
I tried NODE_PATH=./node_modules yarn start without any success.
Thanks a lot for your help.
Regards
I think i get what i want with :
https://yarnpkg.com/blog/2016/11/24/offline-mirror/
I create a cache folder with all tar.gz dependencies downloaded.
But if i remove node_modules and yarn.lock, and run yarn install --offline --cache-folder npm-packages-offline-cache/, I got error saying it could not find proper dependance in cache folder. It's like it cannot recognize any tar.gz inside. Any help will be welcome.
Regars
I've recently started using lerna to manage a monorepo, and in development it works fine.
Lerna creates symlinks between my various packages, and so tools like 'tsc --watch' or nodemon work fine for detecting changes in the other packages.
But I've run into a problem with creating docker images in this environment.
Let's say we have a project with this structure:
root
packages
common → artifact is a private npm package, this depends on utilities, something-specific
utilities → artifact is a public npm package
something-specific -> artifact is a public npm package
frontend → artifact is a docker image, depends on common
backend → artifact is a docker image, depends on common and utilities
In this scenario, in development, everything is fine. I'm running some kind of live reload server and the symlinks work such that the dependencies are working.
Now let's say I want to create a docker image from backend.
I'll walk through some scenarios:
I ADD package.json in my Dockerfile, and then run npm install.
Doesn't work, as the common and utilities packages are not published.
I run my build command in backend, ADD /build and /node_modules in the docker file.
Doesn't work, as my built backend has require('common') and require('utilities') commands, these are in node_modules (symlinked), but Docker will just ignore these symlinked folders.
Workaround: using cp --dereference to 'unsymlink' the node modules works. See this AskUbuntu question.
Step 1, but before I build my docker image, I publish the npm packages.
This works ok, but for someone who is checking out the code base, and making a modification to common or utilities, it's not going to work, as they don't have privledges to publish the npm package.
I configure the build command of backend to not treat common or utilities as an external, and common to not treat something-specific as an external.
I think first build something-specific, and then common, and then utilities, and then backend.
This way, when the build is occuring, and using this technique with webpack, the bundle will include all of the code from something-specfic, common and utilities.
But this is cumbersome to manage.
It seems like quite a simple problem I'm trying to solve here. The code that is currently working on my machine, I want to pull out and put into a docker container.
Remember the key thing we want to achieve here, is for someone to be able to check out the code base, modify any of the packages, and then build a docker image, all from their development environment.
Is there an obvious lerna technique that I'm missing here, or otherwise a devops frame of reference I can use to think about solving this problem?
We got a similar issue and here is what we did: Put the Dockerfile in the root of the monorepo (where the lerna.json locates).
The reason: You really treat the whole repo as a single source of truth, and you want any modification to the whole repo to be reflected in the docker image, so it makes less sense to have separate Dockerfiles for individual packages.
Dockerfile
FROM node:12.13.0
SHELL ["/bin/bash", "-c"]
RUN mkdir -p /app
WORKDIR /app
# Install app dependencies
COPY package.json /app/package.json
COPY yarn.lock /app/yarn.lock
COPY packages/frontend/package.json /app/packages/frontend/package.json
COPY packages/backend/package.json /app/packages/backend/package.json
COPY lerna.json /app/lerna.json
RUN ["/bin/bash", "-c", "yarn install"]
# Bundle app source
COPY . /app
RUN ["/bin/bash", "-c", "yarn bootstrap"]
RUN ["/bin/bash", "-c", "yarn build"]
EXPOSE 3000
CMD [ "yarn", "start" ]
package.json
{
"private": true,
"workspaces": [
"packages/*"
],
"scripts": {
"bootstrap": "lerna clean --yes && lerna bootstrap",
"build": "lerna run build --stream",
"start": "cross-env NODE_ENV=production node dist/backend/main",
},
"devDependencies": {
"lerna": "^3.19.0",
"cross-env": "^6.0.3"
},
}
Late to the party but my approach is using webpack in conjunction with webpack-node-externals and generate-package-json-webpack-plugin, see npmjs.com/package/generate-package-json-webpack-plugin.
With node externals, we can bundle all the dependencies from our other workspaces (libs) into the app (this makes a private npm registry obsolete). With the generate package json plugin, a new package json is created containing all dependencies except our workspace dependencies. With this package json next to the bundle, we can do npm or yarn install in the dockerfile.
I've been trying to convert and deploy one of our node.js apps into a lambda function and have been having some problems with the node_modules dependencies - saying that it can't find certain modules. I started by creating a package.json, npm install the dependencies locally then copy the node modules folder up to lambda.
For instance I have a project that requires sequelize and convict and have been getting errors saying that it cannot find the moment module as a sub-dependency. I see that moment is included in the root of my node_modules but it was not included in the sub folder under the sequelize module.
However, this project runs fine locally. What is the difference in lambda and what's the best practice for deploying a somewhat long list of node modules with it - just a copy of the node_modules folder? On some of the other simpler projects I have, the small amount of node_modules can be copied up with no problems.
{
"errorMessage": "Cannot find module 'moment'",
"errorType": "Error",
"stackTrace": [
"Function.Module._resolveFilename (module.js:338:15)",
"Function.Module._load (module.js:280:25)",
"Module.require (module.js:364:17)",
"require (module.js:380:17)",
"VERSION (/var/task/node_modules/sequelize/node_modules/moment-timezone/moment-timezone.js:14:28)",
"Object. (/var/task/node_modules/sequelize/node_modules/moment-timezone/moment-timezone.js:18:2)",
"Module._compile (module.js:456:26)",
"Object.Module._extensions..js (module.js:474:10)",
"Module.load (module.js:356:32)",
"Function.Module._load (module.js:312:12)"
]
}
I resolved this by uploading all from a zip file which contains all the data I need for my lambda function.
you can just create your project in your local machine and make all the changes that you need then the file you are going to zip should have this same structure and also see that there is an option to load your code from a zip file.
This sounds to me like an issue caused by different versions of npm. Are you running the same version of nodejs locally as is used by Lambda (ie. v0.10.36)?
Depending on the version of npm you're using to install the modules locally, the node_modules directory's contents are laid out slightly differently (mainly in order to de-duplicate things), and that may be why your dependencies can't find their dependencies in Lambda.
After a bit of digging, it sounds like a clean install (ie. rm your node_modules directory and run npm install) might clean things up for you. The reason why is that it seems that npm doesn't install sub-dependencies if they're already present at the top level (ie. you installed moment before sequelize, etc).