npm

npm

DevOps / Build, Test, Deploy / Front End Package Manager

Decision about ESLint, Prettier, Babel, npm, Yarn, Node.js, Webpack, ES5, ES6

Avatar of johnnyxbell
Sr. Software Engineer at StackShare ·

So when starting a new project you generally have your go to tools to get your site up and running locally, and some scripts to build out a production version of your site. Create React App is great for that, however for my projects I feel as though there is to much bloat in Create React App and if I use it, then I'm tied to React, which I love but if I want to switch it up to Vue or something I want that flexibility.

So to start everything up and running I clone my personal Webpack boilerplate - This is still in Webpack 3, and does need some updating but gets the job done for now. So given the name of the repo you may have guessed that yes I am using Webpack as my bundler I use Webpack because it is so powerful, and even though it has a steep learning curve once you get it, its amazing.

The next thing I do is make sure my machine has Node.js configured and the right version installed then run Yarn. I decided to use Yarn because when I was building out this project npm had some shortcomings such as no .lock file. I could probably move from Yarn to npm but I don't really see any point really.

I use Babel to transpile all of my #ES6 to #ES5 so the browser can read it, I love Babel and to be honest haven't looked up any other transpilers because Babel is amazing.

Finally when developing I have Prettier setup to make sure all my code is clean and uniform across all my JS files, and ESLint to make sure I catch any errors or code that could be optimized.

I'm really happy with this stack for my local env setup, and I'll probably stick with it for a while.

17 upvotes·3 comments·34.1K views

Decision at UI licious about Go, npm, Node.js

Avatar of PicoCreator
CTO at Uilicious ·

Our CLI was originally written Node.js with npm , 2 years ago. We have now migrated to Go !

It was something we quickly hacked together at the early beginnings of Uilicious when our focus was to move fast and iterate the product quickly. We wanted to roll out the CLI ASAP, so that users with a CI/CD can hook up their tests to their front-end deployment pipeline.

However after 2 years, with NPM dependency hell pains - We decided to migrate our CLI toolchain to Go for

  • Zero deployment dependencies
  • Single file distribution (and backwards compatible with NPM)

Happy with how it is : article covers the decision in much deeper details

https://dev.to/uilicious/why-we-migrated-our-cli-from-nodejs-to-golang-1ol8

14 upvotes·35.8K views

Decision about Yarn, npm, PackageManagers

Avatar of aharonamir
YarnYarnnpmnpm
#PackageManagers

#PackageManagers After a long time where npm failed to install packages and lot's of googling on answers, we switched to Yarn and alomost all those problems where solved. Today i mostly use "yarn add" instead of "npm install --save".

12 upvotes·4 comments·8.8K views

Decision at Epsagon about AWS Lambda, GitHub, Java, Go, Node.js, npm, Serverless, Python

Avatar of nshap

At Epsagon, we use hundreds of AWS Lambda functions, most of them are written in Python, and the Serverless Framework to pack and deploy them. One of the issues we've encountered is the difficulty to package external libraries into the Lambda environment using the Serverless Framework. This limitation is probably by design since the external code your Lambda needs can be usually included with a package manager.

In order to overcome this issue, we've developed a tool, which we also published as open-source (see link below), which automatically packs these libraries using a simple npm package and a YAML configuration file. Support for Node.js, Go, and Java will be available soon.

The GitHub respoitory: https://github.com/epsagon/serverless-package-external

10 upvotes·1 comment·50.2K views

Decision at Gentlent about Visual Studio Code, npm, Varnish, HAProxy, Kubernetes, Docker, GitLab, GitHub, Git

Avatar of tomklein
CEO at Gentlent ·

We're using Git through GitHub for public repositories and GitLab for our private repositories due to its easy to use features. Docker and Kubernetes are a must have for our highly scalable infrastructure complimented by HAProxy with Varnish in front of it. We are using a lot of npm and Visual Studio Code in our development sessions.

9 upvotes·10.5K views

Decision at Compass Inc. about npm, Amazon CloudFront, AWS Lambda, Semver, Lambdaatedge

Avatar of brenzenb
Engineering Manager at Compass ·
npmnpmAmazon CloudFrontAmazon CloudFrontAWS LambdaAWS Lambda
#Semver
#Lambdaatedge

At Compass, we’re big proponents of using NPM and semver (semantic versioning) when distributing our shared components as packages. NPM provides us with an industry-standard platform to publish our internal dependencies. The tools and technologies someone learns while working on a package at Compass are the same ones they’ll use in projects in the open source community. Meanwhile, semantic versioning itself plays a huge role in providing peace of mind. Users of shared components know when updates are safe enough to upgrade to, and component authors can make big updates without the fear of silently breaking the contracts they’ve made with their users. We wanted to build out a way to provide these same benefits to more than just JS libraries, and we ended up creating a lightning-fast form of semantic versioning for our CSS implementation that utilized Lambda@Edge, NPM, and some clever work by our engineers.

AWS Lambda Amazon CloudFront npm #lambdaatedge #semver #serverless

8 upvotes·2.9K views

Decision about nginx, Webpack, Vue.js, Framework7, npm, MySQL, Ubuntu, Node.js, Plaid, Framework7, HapiJS, Lenovo

Avatar of mbplautz

I just designed, developed, and deployed my own budgeting app, dailybudget.cc, which allows me to automate my budgeting the way I have always done it, in a way that I could never fully capture with other budgeting apps, such as Mint, EveryDollar, or YNAB. I spent 4 years from the time I first had the idea to the time I actually sat down to design it and start development. During this time I evaluated many other budgeting app solutions, and had even architected a prototype that I never ended up using. But boy, have technologies come much further in 4 years.

Though my first prototype used Java and Tomcat, I completely abandoned those 4 years later in favor of Node.js technologies, which I have found are equally as stable, more flexible (for better or for worse), and capable of significantly more rapid development. Since what I have deployed now is in beta and is primarily for limited user use, I favored rapid development over slower development where I would write more automated unit tests. I chose to build the app as a HTML5 web application (rather than native iOS or Android, for now), and I used a separated API backend/Web frontend model. My target platform for use with the app is mobile handheld touch devices, though it can work on any laptop or desktop with a touchscreen. Given these design targets, many of the technologies I chose were because of familiarity with them as well as a strong online community, and some technologies I chose that I had to learn anew, because they appeared to fit my needs.

My entire app runs on a #lenovo IdeaCentre desktop on my home network, on which I have installed Ubuntu 18.04. Ubuntu is something I have switched to after a long time of use and familiarity with RedHat Enterprise Linux and CentOS, because the online support for Ubuntu is now tremendous, and there is so much documentation and examples online of how to configure and use Ubuntu; not to mention I have not been thrilled with the direction new releases of CentOS. Ubuntu is also a good environment for development - it is so easy to follow the many online examples. Lastly, I may migrate my app and configuration to Amazon AWS, which also uses Ubuntu for its EC2 Linux VMs, so having Ubuntu now is helpful for that prospect.

The API backend uses Node.js, with #HapiJS as the API server framework and MySQL as my persistence database. HapiJS is something I have had familiarity with and is just a phenomenal framework to plug into and configure, especially if you use it for a route-based API. #Mysql has a great online community. I could've used PostgreSQL too, but I am more familiar with MySQL. Also, if I migrate to Amazon AWS, Amazon's RDS uses MySQL. I use npm as a one-stop-shop package manager and environment manager.

The Web frontend uses a combination of Framework7 and Vue.js. I cannot evangelize Framework7 enough! It is a fantasic tool by @nolimits4web (GitHub) that is really easy to use, really well thought out, and really performant. Framework7 simulates the native iOS or Android (Google Material) experiences, all using HTML5 constructs (HTML+CSS+JS). Vue.js is another very fantastic binding and frontend framework which has a good online community and is well documented and easy to use. I had to choose between VueJS and ReactJS, and ultimately chose VueJS over ReactJS because it seemed to favor more rapid development with less ramp-up time, whereas I understood ReactJS to be more of an enterprise level framework (though still good for smaller projects like mine). When using Framework7 with VueJS, NodeJS is used along with Webpack to transpile my code into browser-friendly JavaScript, HTML, etc. Webpack was nice to use because it has a hot-deploy development mode to enable rapid development without me having stop, recompile, and start my server (this was one of several reasons against using Java with Tomcat). I had no familiarity with Framework7, VueJS, or Webpack prior to this project.

I use nginx as my web server and have the API running behind a reverse proxy, and all of the web frontent content hosted as static content.

I use the plaid API to sync my bank transactions to my database. This is another fantastic framework (though not free beyond development use) that it turns out is extremely easy to use for the complex job that it solves.

7 upvotes·2 comments·18K views

Decision about Material Design for Angular, gRPC, TypeScript, Webpack, npm, Angular 2

Avatar of omidfarhang
Sr. Full Stack Developer ·

I really enjoy my project when I use Angular 2 and above because I have full control over everything and easy I can make it #SSR and add everything I need using npm and let Webpack to bundle them all, Thanks to TypeScript for making it easy to write minimal and manageable code. It was so easy to integrate gRPC into our project. Since we have been using Material Design for Angular we spend all our time on writing Clean Code and not much time for UI.

5 upvotes·8.4K views

Decision at StackShare about npm, Yarn

Avatar of ruswerner
Lead Engineer at StackShare ·

We use Yarn because at the time we decided to adopt it, npm had some missing features and issues. We like the speed and determinism provided by Yarn. We could probably use npm at this point, but we have no real reason to switch from Yarn. If you have a convincing argument to switch from npm to Yarn please leave a comment on this decision!

5 upvotes·4.5K views

Decision about npm

Avatar of Pustelto

I use npm since new version is pretty fast as well (Yarn may be still faster a bit but the difference isn't huge). No need for other dependency and mainly Yarn sometimes do not work. Sometimes when I want to install project dependencies I got error using Yarn but with npm everything is installed correctly.

5 upvotes·1.4K views