Skip to main content

Home/ Larvata/ Group items tagged npm

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
張 旭

The package-lock.json file - 0 views

nodejs.dev/...the-package-lock-json-file

nodejs

shared by 張 旭 on 22 May 22 - No Cached
  • You don't commit to Git your node_modules folder, which is generally huge, and when you try to replicate the project on another machine by using the npm install command,
  • Even if a patch or minor release should not introduce breaking changes
  • The package-lock.json sets your currently installed version of each package in stone, and npm will use those exact versions when running npm ci
  • ...1 more annotation...
  • The package-lock.json file needs to be committed to your Git repository
  • 張 旭 on 22 May 22
     
    "You don't commit to Git your node_modules folder, which is generally huge, and when you try to replicate the project on another machine by using the npm install command,"
crazylion lee

shrinkwrap | npm Documentation - 0 views

docs.npmjs.com/shrinkwrap

nodejs npm node

shared by crazylion lee on 11 Jul 16 - No Cached
  • crazylion lee on 11 Jul 16
     
    "Lock down dependency versions"
張 旭

Containers Vs. Config Management - 0 views

blog.containership.io/config-management-e64cbb744a94

docker devops deploy config ansible puppet system

shared by 張 旭 on 16 Feb 17 - No Cached
  • With configuration management systems, you write code that describes how you want some component of your systems to be installed and configured, and when you execute the code on your server, it should end up in the desired state.
  • building a hosting platform that is capable of a lot of things that system administrators used to do manually
  • build modules on deployment via bundler or npm or similar, it can be incredibly slow to run, taking minutes or longer in some cases
  • ...10 more annotations...
  • pulling from git is slow.
  • deploying with configuration management tools is a pain in the ass and error prone.
  • Support for containers has existed in the Linux kernel since version 2.6.24 when cgroup support was added
  • All of the logic that used to live in your cookbooks/playbooks/manifests/etc now lives in a Dockerfile that resides directly in the repository for the application it is designed to build
  • All of the dependencies of the application are bundled with the container which means no need to build on the fly on every server during deployment.
  • Containers bring standardization which allows for systems like centralized logging, monitoring, and metrics to easily snap into place no matter what is running in the container.
  • Dockerfiles do not give you the same level of control over configuration as your application transitions between environments, like dev, staging, and production.
  • You may even need to have different Dockerfile’s for each environment in certain cases.
  • configuration management systems now have hooks for docker integration.
  • Config management will only be used to install Docker, an orchestration system, configure PAM/SSH auth, and tune OS sysctl values.
  • 張 旭 on 16 Feb 17
     
    "With configuration management systems, you write code that describes how you want some component of your systems to be installed and configured, and when you execute the code on your server, it should end up in the desired state."
張 旭

An App's Brief Journey from Source to Image · Cloud Native Buildpack Document... - 0 views

buildpacks.io/app-journey

devops buildpacks package docker

shared by 張 旭 on 02 Aug 19 - No Cached
  • A buildpack’s job is to gather everything your app needs to build and run, and it often does this job quickly and quietly.
  • a platform sequentially tests groups of buildpacks against your app’s source code.
  • transforming your source code into a runnable app image.
  • ...2 more annotations...
  • Detection criteria is specific to each buildpack – for instance, an NPM buildpack might look for a package.json, and a Go buildpack might look for Go source files.
  • A builder is essentially an image containing buildpacks.
crazylion lee

Uppy - 0 views

uppy.io

npm upload dropbox

shared by crazylion lee on 09 Jan 18 - No Cached
張 旭

mvn clean install - a short guide to Maven - 0 views

www.marcobehler.com/...install-a-short-guide-to-maven

programming java

shared by 張 旭 on 12 Aug 20 - No Cached
  • An equivalent in other languages would be Javascript’s npm, Ruby’s gems or PHP’s composer.
  • Maven expects a certain directory structure for your Java source code to live in and when you later do a mvn clean install , the whole compilation and packaging work will be done for you.
  • any directory that contains a pom.xml file is also a valid Maven project.
  • ...17 more annotations...
  • A pom.xml file contains everything needed to describe your Java project.
  • Java source code is to be meant to live in the "/src/main/java" folder
  • Maven will put compiled Java classes into the "target/classes" folder
  • Maven will also build a .jar or .war file, depending on your project, that lives in the "target" folder.
  • Maven has the concept of a build lifecycle, which is made up of different phases.
  • clean is not part of Maven’s default lifecycle, you end up with commands like mvn clean install or mvn clean package. Install or package will trigger all preceding phases, but you need to specify clean in addition.
  • Maven will always download your project dependencies into your local maven repository first and then reference them for your build.
  • local repositories (in your user’s home directory: ~/.m2/)
  • clean: deletes the /target folder.
  • mvn clean package
  • mvn clean install
  • package: Converts your .java source code into a .jar/.war file and puts it into the /target folder.
  • install: First, it does a package(!). Then it takes that .jar/.war file and puts it into your local Maven repository, which lives in ~/.m2/repository.
  • calling 'mvn install' would be enough if Maven was smart enough to do reliable, incremental builds.
  • figuring out what Java source files/modules changed and only compile those.
  • developers got it ingrained to always call 'mvn clean install' (even though this increases build time a lot in bigger projects).
  • make sure that Maven always tries to download the latest snapshot dependency versions
張 旭

Optimizing Gitlab pipelines - Basics (1) | PrinsFrank.nl - 0 views

prinsfrank.nl/...g-gitlab-pipelines-pt-1-basics

devops gitlab cicd proxy performance

shared by 張 旭 on 23 Feb 22 - No Cached
  • When you use specific docker image, make sure you have the Dependency Proxy enabled so the image doesn’t have to be downloaded again for every job.
  • stages are used to group items that can run at the same time.
  • Instead of waiting for all jobs to finish, you can mark jobs as interruptible which signals a job to cancel when a new pipeline starts for the same branch
  • ...8 more annotations...
  • mark all jobs as interruptible as it doesn’t make sense to wait for builds and tests based on old information.
  • Deployment jobs are the main exception as they should probably finish.
  • only running it when specific files have changed
  • To prevent the ‘vendor’ and ‘node_modules’ folder from being regenerated in every job, we can configure a build job for composer and npm assets.
  • To share assets between multiple stages, Gitlab has caches and artifacts. For dependencies we should use caches.
  • The pull-push policy is the default, but specified here for clarity.
  • All consecutive runs for the build step with the same ‘composer.lock’ file don’t update the cache.
  • composer prevents this by caching packages in a global package cache,
1 - 7 of 7
Showing 20▼ items per page