How to generate JHipster application into a specific directory? - node.js

Suppose I modified the source code of generator-jhipster repo and I would like to generate my "custom" JHipster application into a specific directory, how would I accomplish this task?
After installing JHipster:
npm install -g generator-jhipster
I would be able to generate the application with:
jhipster
However, this command runs the application directly from the JHipster repository.
Since I modified the source code, I could generate the application locally by running:
node jhipster.js
in the ../cli directory.
The problem is, running this command in cli directory will generate the application in the same directory (cli) and this is not what I want.
I need to find a way to export the application into a specific directory.
Note: I strongly believe this has something to do with process.cwd(), because that generates the application in the local directory, but I'm not sure exactly
which source file to modify as I don't want to break anything.

Related

How to automate batch command file for globally installed package?

Good day!, I don't know if my question is correct. but what happens here is I created my own local development environment with the portable binaries. Please see:
Everything is working fine except for NPM. Everytime I install a global package in NPM I first need to create a batch file to call the .cmd from the node directory.
E.g. After installing Angular CLI, I need to create a batch file pointing to the ng.cmd file. Please see: (node directory)
And here is my ng.bat file in the cli folder: (cli directory)
The reason why I did this because I don't want to mess up my windows PATH environment settings. Here is my PATH variables where I already added my cli folder:
Is there a way of automating these? instead of creating manually a batch file in my cli folder every time I add a new package or binaries?
Best Regards

How to: git repository with default NPM modules and its configs

I would like to have repository with default NPM modules and its configs for all future NPM projects.
For now the configs consists of tsconfig.json, tslint.json, .prettierrc.
The goal is to have a simple way for creating new project with custom defaults and also have possibility of changing configs for all of these projects from one place.
I tried to create my own NPM module with package.json containing dependencies I want to have in all my new projects and its configs in root. The problem is obvious - if I install this package into new project, modules (and configs) are scoped to my custom module and not to my newly created project.
Does anyone has any idea how to deal with this?
You are basically making a boilerplate. Do develop it, I see two possible approcches:
Publish the boilerplate as NPM module.
Build and publish the boilerplate on your repository provider (Github, Bitbucket etc) and use it as starting project to be forked for every new project you build.
I will suggest you to follow the second approach, that's easier to achieve.
You are instead tryng to follow the first approch that's more tricky. To generate a starting project you should build a CLI (Command line interface). So you will build an NPM module that should be globally installed and that you will use with a set of commands like:
myawesomecli generate my-new-starting-project
And the myawesomecli module will generate a my-new-starting-project folder containing your boilerplate. You could optionally ask to the user for settings to be selected in an interactive session. That's what famous framework like React, Vue.js, Angular etc. are doing.
You can follow this tutorial to build a CLI that generates boilerplates. Keep in mind that the inquier module is the key module for such scopes.

How to modify an npm package built with TypeScript

I want to try and make some changes to a package published in npm? (I've suggest some changes as an issue but I think they are simple enough for me to attempt them).
https://www.npmjs.com/package/bt-presence#contributing--modifying
The author supplies some information on how to modify the package, but not really enough for someone doing it for the first time.
Where should I clone the GitHub repo to? The folder where the package is installed? I tried it in my home folder and that would not build (unmodified).
The command npm run build - where is this run from? The root folder of the package where the package.json is?
Will I need to modify the package.json?
In general what is the best way to develop something like this for npm? I've worked on packages before but they were simply Javascript.
If you want to work on the bt-presence package in isolation, you can put the cloned repository anywhere. If you want to use your modified version of bt-presence in combination with an application, my recommended approach is to register bt-presence as a dependency in the application's package.json file with the version set to a relative path to your bt-presence repository; then running npm install in the application will make a symlink from node_modules/bt-presence in the application to your bt-presence repository.
npm run build should indeed be run from the root folder that contains the package.json of bt-presence.
If you just want to change the code of bt-presence, you won't need to modify its package.json. You would only modify the package.json if you need to change any of the settings in there, e.g, if you need to add additional dependencies to your version of bt-presence.
None of the above is really specific to TypeScript. (Some JavaScript packages have build processes too if they need to transform or package the JavaScript files in some way.)

JHipster: Why node_modules and other front-end files got generated for --skip-client flag?

I created a new JHipster project with the following command:
jhipster --skip-client
Since, I skipped client generation via --skip-client, why the newly created project contains the following files and folders which I think are related to frontend and not related to backend anywhere:
node_modules
package.json
.yo-rc.json
yarn.lock
From this link, it seems like it is actually a feature and not a bug.
The purpose of installing a local copy of generator-jhipster is that if you upgrade your global version, the local version will still match what your project uses. This protects you from using a newer entity generator on an older project. You can skip the installation of the local generator-jhipster by using --skip-install (note that your project will then always use the global generator-jhipster)
The .yo-rc.json file has the answers to your prompt and other details about your project that help with the other subgenerators such as entity or import-jdl. This file is important to keep.

Testing a module

I just implemented a Jhipster module to provide Maven site generation as well as maven release process within Jhipster.
I implemented mocha tests to verify that files are generated (which pass), but it looks like they aren't generated in a real scaffolded context (if you have any clue on the error, I would be really thankful).
The only way I found to test that module with a scaffolded sample is to publish it in the npm registry in order to be able to select it in module choices radio, but it's not really a good option, as it exposes a non working module on the Jhipster marketplace (I'm really sorry about it).
To test a module locally, do the following:
run npm link in your module directory
generate a project
run npm link generator-jhipster-enterprise-pom in your project
Now when you run yo jhipster-enterprise-pom it will use your local code instead of requiring installation from npmjs.
Looking at your module's code, it looks like you renamed the app folder to server. A yeoman generator runs the code found in the app folder which is why your local test is failing. According to the Writing Your Own Yeoman Generator docs:
The default generator used when you call yo name is the app generator. This must be contained within the app/ directory.
It's currently accessible by running yo jhipster-enterprise-pom:server but I imagine you don't want the :server included in the default command.

Resources