when you generate a yeoman project, do you commit the node_modules that is generated into your code repository?
It seems like it is necessary for another developer to check out a project and develop from it, but it seems like a lot of files to commit which seem unrelated to a project itself.
You can just run npm install to get the dependencies installed. However there are multiple benefits to committing your dependencies, which you can read about in this blog post:
Checking in front-end dependencies (for Bower, but applies to npm too)
Related
I am setting up github actions, and struggling to see how to handle the dependencies of a particular action.
Below is a simplified view of my repository setup, with the action and workflow YAML files as I currently understand them.
my-org/my-tool#master: a specific tool in my organisation that I want to enable as a github action
package.json
tool.js: the tool, depending on npm packages described in package.json
action.yml
name: my-tool
inputs:
file:
description: file to be processed by my-tool
required: true
runs:
using: node16
main: tool.js
my-org/my-code#branch: a code repository where I want to run the tool as an action
my-code.js: some code that needs to be processed by the tool
.github/workflows/use-tool.yml:
# ...
jobs:
tool:
steps:
- uses: my-org/my-tool#master
with:
file: my-code.js
# ...
If my-tool has no dependencies, this setup works well enough. But my-tool needs to have dependencies installed to function properly, i.e., a single npm install in its root directory. How do I specify this dependency in a github action setup?
I have multiple options, none of which are truly satisfying to me:
I can define a workflow that checks out my-tool, installs the dependencies, and then runs it. However, I don't want that logic to be in the workflow yaml of the my-code repository, as I have multiple similar repositories, all of which require my-tool, which will result in duplication. I don't see how to do this in the action.yml file itself. It seems I have to choose between a javascript action to run node tools, or a composite action to run shell tools.
I can bundle the node_modules directory in the my-tool repository; this bloats my repos unnecessarily.
I can bundle an ncc distribution of my-tool in its repo; same problem.
I can define and build a container image of my-tool with its dependencies installed, and use a container action to run the tool on my-code. This seems like overhead to me, and I have no idea how this container would access the files from the my-org/my-code repo (which would be its core purpose).
Options 2 and 3 are the ones described in the example published by github. I would be happy with using an artifact (either node_modules dir or ncc distribution) as the basis for an action, but there seems to be no way to do this.
My specific use case concerns npm dependencies, but there seems to be a generic use case for "action with dependencies", support for which is unclear to me from reading the documentation. I can't be the only dev in the world working with a toolset with dependencies of its own. Maybe I am looking at this setup in the wrong way. Is there a best practice for actions with dependencies? Is there a best practice to only have actions with zero dependencies?
I look forward to learn from any partial answer or suggestion.
So I installed some modules with npm and others I just copied and pasted into the node_modules folder. One module I had to hack.
Now when I perform npm install for a new module, it deletes some of the modules and overwrites the hacked one to its original state.
It feels like I didn't run npm init early enough in development to properly set my package.json file from the start and now when I do run npm init it only picks up some of the modules.
How can I get everything synced up again? Is there a way to take a node_modules folder and get npm to become familiar with all the modules again? Also, is there any way to prevent the hacked one from going back to its original state?
Thank you!
Here's an answer to a similar question
You can fork the repo of the "hacked" module and include the forked repo in your package.json file. As for the "copied" modules, you can either copy them outside your node_modules folder and import using relative paths, or install it as a local npm package.
I'm creating a yeoman generator for my web projects.
But I wonder how I can try and test my changes before publishing it?
Since I have installed it once, it will not run my local development version, instead it runs my installed version.
Any suggestions on how can test-run my local development version?
I finally found some information on how to accomplish this:
if you wish to develop on the generators code base, and debug locally, a common way to do so is to rely on npm link
git clone the generators repo locally
cd into that repository and run npm link. It'll install required dependencies and install the package globally, using a symbolic link to your local version.
If you want to install sub generators, you need to do so in the context of a yeoman-generator package linked earlier. Cd into the sub generators package you have cloned locally and run npm link.
We now have everything linked and known on the system, we now need to link the sub-generator repo into the parent one, yeoman-generator cloned and linked in step 1 & 2.
https://github.com/yeoman/generator/wiki/Testing-generators
EDIT:
Updated link for info: https://yeoman.io/authoring/index.html
If by "running locally" you mean the ability to test your generator and its flow you can simply do this.
In your project directory folder run npm link. If this passes in flying colors, go to step 2.
Open a terminal and cd into the folder you wish to initiate a project.
Run yo generator-theNameOfYourGenerator. This will run your generator.
I am currently creating a portable consolidation of my workflow using Node-Webkit which has node.js embedded. Now my problem is getting grunt/gulp inside the project itself as it depends on the cli somewhat(avoidable, granted), and also is confusing to me on the architecture. Is it possible to find just a .js with grunt in it to include much like Jquery/Handlebars?
Is this all I need to just include and run?
No before that make sure you environment is up, get the package.json, GruntFile.js file. In GruntFile.js you can specify what you want to pre-process. For example jade,Less,coffee. It looks very much like a node function, for sample you can refer to link
Now to make this work you also need to install various contrib plugins as per your requirement. Then register every single task in GruntFile.js. It really speeds up the development.
grunt.loadNpmTasks('grunt-contrib-less');
grunt.loadNpmTasks('grunt-contrib-jade');
grunt.loadNpmTasks('grunt-contrib-coffee');
grunt.registerTask('test', ['jade', 'less','coffee']);
So to process less,jade,coffee, we need to run the module installations such as
npm install grunt --save-dev
npm install grunt <module name> --save-dev
There are many more interesting configurations to learn and documentation is really nice, please refer to getting started guide
This adds the required Grunt and grunt plugins to package.json
I have an existing Mercurial repository for a C++ application in a small corporate environment. I asked a co-worker to add the setup script to the repository and he added all of the dependency binaries, PDFs, and executable to the repository under an Install directory. I dislike having the binaries and dependencies in the same repository, but I'd like recommendations on best practices. Here are the options I am considering:
Create a separate repository for the
Installer and related files
Create a subrepository for the
Installer and related files
Use a (yet to be identified) build
dependency manager
I am concerned with using a subrepository with Mercurial based on what I've read so far and the (apparently) incomplete implementation. I would like to get a project dependency system, e.g. Ivy, but I don't know all of the options and haven't had time yet to try out any options.
I thought I'd use TortoiseHg as a basis, and it does not have the TortoiseHg binaries in the repository although it does have some binaries such as kdiff3.exe. Instead it uses setup.py to clone multiple repositories and build the apps. This seems reasonable for OSS, but not so much for corporate environments.
Recommendations?
I've had great luck using a good dependency manager, but it's more useful for code modules than artifacts. A sub-repo certainly works, but you'll not be cutting the clone time of people pulling the top tree since it will cascade into the subrepo too.
Someone will probably suggest using bfiles or big files, but I'd avoid it. They work well enough, but that functionality looks like it's going into mercurial this summer natively at which time those will languish.
Were I you I'd (a) hit the co-worker (b) try to strip those added files (using strip or convert), (c) re-do it will the installers being built not stored.
The PDFs I'd probably store, but there are some neat tricks for generating docs if you're interested.