I was looking for something that can update the code automatically on certain conditions. It is similar to how the new dependencies are added to the package.json file, when we do an npm install.
How to make it possible ?
Explaining Further - When I run a command (in node), I have some code in some other folder (Angular)- the command will update the code like for example inserting new imports.
If you want to use Angular CLI +1.7 and update all dependency package you can use ng upadte
running the ‘update’ command will check for changes in the auto
generated files that come with angular projects out-of-the-box and you
be ask if you want to overwrite the existing with the new. You will
also be prompted to choose from four options, y(yes), n(no),
d(difference) and h(help). Choose with discretion.
Related
I have a npm package that we use for multiple projects. Currently when I want to make a change to something on these projects that requires a change on the npm package I need to make a change to the npm package, submit a pr, wait for someone to merge it for me and then I can actually test the changes I made on the other projects (no testing is set up currently sadly).
What I want to do is on the other projects have a way to install / use the local module instead of the global one so I can test the full flow before I submit any prs. Im using config package and ideally I can set it up so if I use a specific config file it defaults to local npm package instead of global.
Is this possible?
Based on what you are describing, take look at the link command offered by package managers to help solve this:
https://classic.yarnpkg.com/en/docs/cli/link#search
https://docs.npmjs.com/cli/v8/commands/npm-link
I have published a global node package via npm to generate boilerplate templates for projects at my company.
I would like to compare the current version with the latest published in order to exit the process if it’s not the latest.
What node libraries would you recommend to check for the latest version.
Is there a way to auto update the global package if a new version is detected.
Remember this is an internal tool for my company so It’s critical they are creating projects with the latest templates and I’d like them to be able to update as automatically or easily as possible
Personal Suggestion
Instead of forcing the user to upgrade, another option is to publish your templates (as zip) on remote static server (e.g. S3). In such case, you can often update the zip to the latest template without upgrading the template generator.
generate-template angularjs-template:latest
generate-template angularjs-template:4.3
Answering Your Questions
What node libraries would you recommend to check for the latest version.
I am not sure if there is a library for this. However, you can build one very easily.
Create a JSON file which contains the package information (e.g. latest stable version, deprecation message, etc.).
Upload the JSON file to a remote static server.
Whenever the user runs your program, download the JSON file and check against the current package.json.
Show a deprecation warning if the user should upgrade.
process.exit() the application if the user must upgrade.
Is there a way to auto update the global package if a new version is detected.
I think it is better to leave the control to the user, because there could be some reasons why he doesn't prefer upgrade. For example, if the user has a bunch of projects started 10 months ago, he might want to use the same template for newer projects.
But if you really want to automate it, you might use the following code (not tested).
const { execSync } = require('child_process');
const pkg = require('./package.json')
execSync(`npm update -g ${pkg.name}`)
process.exit()
Starte of the art:
Popular node.js frameworks come with their own starter-kits that act as project templates, such as React comes with the starter-kit .
When user want to create a new react application, they can use the short hand npx create-react-app my-app. ... to automagically create the whole project scaffold with all baseline project files, directories, and package dependencies.
When using the starter-kit, npx resolve template variables inside the starter-kit files i.e. if package.json contains an entry {{my-application-name}}, npx will as for user input to replace the template variable with e.g. "my-first-app".
React is just one example for such a starter-kit.
Problem statement:
I would like to build my own starter-kit for my own node.js framework.
At the first glance, it seems that one just follow the convention to name my package starting with "create-" and use the template-{{vars}} at the right places.
I gave it a try and started copy&paste&replace, however npm install did not work, since unresolved template variable result in build errors.
Does somebody know a tutorial how to create your own npx starter-kit?
Do somebody know how one can build and publish a new starter kit?
yes, you can build your own npx starter by using the CLI helper packages on the npm registery
Steps for how to build your own npx starter...?
you can use args or commander to get the cli
inputs ( node argv withing the process object ) and parse it
into object so you can keep track of what the user want
based on the the previous parsed object from the CLI now you can
gather more information by using inquirer where
you can ask yes/no questions or choose one of many options.
after the user answer all the questions you now can write the logic
for creating the required starter based on the inputs of the user
you can use execa to perform process command such as git
init , git clone or any command that might comes to your own mind
you can use listr to prettify your own task lists with a
beutiful spinner
you can use chalk to print the line in the CLI with colors
and make it easier to read make the message green if it's success or red when it's failed
for more explanation on how it works together you can see this video
I've built a custom style "skin" on top of bootstrap that I intend to use in multiple UI projects.
Rather than copying/pasting the UI styles/components (built using sass and typescript in my current Angular 5 project), I want to build an NPM package that I can install these styles and components I've built in new projects, thus allowing updates to be done to the NPM package (maybe extending the controls within for example) without breaking the UI's using them or needing to update files within.
I've never setup an NPM project before. I've found a number of examples of how to build NPM packages, for example https://codeforgeek.com/2014/08/how-to-create-nodejs-npm-package/ but it seems to be for vanilla JS in this example. I need an example which:
Builds on a dependency, in this case bootstrap
Is to be used in Angular (I'm using version 5)
Is installable and updatable via NPM or maybe Yarn
Has anyone any top tips on achieving the above? Or any really clear guides where someone has done this before?
I realise this question is relatively broad but really I just need some pointers to get started and I will document the process further when I have a better understanding.
Thanks in advance!
So you should move your theme into a separate project. Then all you have to do is run npm init in that directory and you have a npm.
As for sharing it between projects, I would create a repo on Github for this theme npm. Push all of your changes there. Then you can reference it in the package.json of all your projects by linking to the Github repo. Here is a good Stack question about how to do that.
Finally, if you want to develop your theme locally inside one of your projects, you can use npm link. Here are he docs on that.
I have a repo which consists of several "micro-services" which I upload to AWS's Lambda. In addition I have a few shared libraries that I'd like to package up when sending to AWS.
Therefore my directory structure looks like:
/micro-service-1
/dist
package.json
index.js
/micro-service-2
/dist
package.json
index.js
/shared-component-1
/dist
package.json
component-name-1.js
/shared-component-2
/dist
package.json
component-name-2.js
The basic deployment leverages the handy node-lambda npm module but when I reference a local shared component with a statement like:
var sharedService = require('../../shared-component-1/dist/index');
This works just fine with the node-lambda run command but node-lambda deploy drops this local dependency. Probably makes sense because I'm going below the "root" directory in my dependency so I thought maybe I'd leverage gulp to make this work but I'm pretty darn new to it so I may be doing something dumb. My strategy was to:
Have gulp deploy depend on a local-deps task
the local-deps task would:
npm build --production to a directory
then pipe this directory over to the micro-service under the /local directory
clean up the install in the shared
I would then refer to all shared components like so:
var sharedService = require('local/component-name-1');
Hopefully this makes what I'm trying to achieve. Does this strategy make sense? Is there a simpler way I should be considering? Does anyone have any examples of anything like this in "gulp speak"?
I have an answer to this! :D
TL;DR - Use npm link to link create a symbolic link between your common component and the dependent component.
So, I have a a project with only two modules:
- main-module
- referenced-module
Each of these is a node module. If I cd into referenced-module and run npm link, then cd into main-module and npm link referenced-module, npm will 'install' my referenced-module into my main-module and store it in my node_modules folder. NOTE: When running the second npm link, the name of the project is the one you find in your package.json, not the name of the directory (see npm link documentation, previously linked).
Now, in my main-module all I need to do is var test = require('referenced-module') and I can use that to my hearts content. Be sure to module.exports your code from your referenced-module!
Now, when you zip up main-module to deploy it to AWS Lambda, the links are resolved and the real modules are put in their place! I've tested this and it works, though not with node-lambda yet, though I don't see why this should be a problem (unless it does something different with the package restores).
What's nice about this approach as well is that any changes I make to my referenced-module are automatically picked up by my main-module during development, so I don't have to run any gulp tasks or anything to sync them.
I find this is quite a nice, clean solution and I was able to get it working within a few minutes. If anything I've described above doesn't make any sense (as I've only just discovered this solution myself!), please leave a comment and I'll try and clarify for you.
UPDATE FEB 2016
Depending on your requirements and how large your application is, there may be an interesting alternative that solves this problem even more elegantly than using symlinking. Take a look at Serverless. It's quite a neat way of structuring serverless applications and includes useful features like being able to assign API Gateway endpoints that trigger the Lambda function you are writing. It even allows you to script CloudFormation configurations, so if you have other resources to deploy then you could do so here. Need a 'beta' or 'prod' stage? This can do it for you too. I've been using it for just over a week and while there is a bit of setup to do and things aren't always as clear as you'd like, it is quite flexible and the support community is good!
While using serverless we faced a similar issue, when having the need to share code between AWS Lambdas. Initially we used to duplication the code, across each microservice, but later as always it became difficult to manage.
Since the development done in Windows Environment, using symbolic links was not an option for us.
Then we came up with a solution to use a shared folder to keep the local dependencies and use a custom written gulp task to copy these dependencies across each of the microservice endpoints so that the dependency can be required similar to npm package.
One of the decisions we made is not to keep two places to define the dependencies for microservices, so we used the same package.json to define the local shared dependencies, where gulp task passes this file and copy the shared dependencies accordingly also installing the npm dependencies with a single command.
Later we made the code open source as npm modules serverless-dependency-install and gulp-dependency-install.