https://github.com/buildtip/create-web-app/blob/57f42070e9180fc1d284af5caeeed6f4bb8552ff/generators/app/templates/TMEN/package.json#L10

In this package project link the main file is running when the package is run is dist/cli.js. Now, this file needs to get a projects from one upper directory. The method I implemented in node is

fs.readFile(`../generators/app/templates/${answer.stack}/package.json`,CB)

But this is checking from in the folder from where the command is running or from the location of the user’s terminal. Not from where this package is installed.

I want a node method or something which can get me the location of the project installed (global location as it is global package) not the location from where it is called.

This is a major issue and till its open , The tool is not working properly.

The next patch release will be resolving this issue.

NPM forum link

Enhancement

1. Adding more web app related to efficient and lightweight boilerplates for the project
2. Upgrading/updating or advancing or improving the existing boilerplates
3. Completing the existing boilerplates
4. Testing the boilerplates

This is issue for submitting feedbacks over new project idea I am working on here #56
Please give your feedback by submitting a PR with your feedback written here https://github.com/buildtip/create-web-app/blob/master/NEW_CLI_FEEDBACK.md

Hacktoberfest friendly issue

Refer this for the implementation https://github.com/babel/babel/pull/10569/files#diff-1d37e48f9ceff6d8030570cd36286a61R114-R133

Enhancement

Need to write major tests for the utility methods and the generators also if any other places if possible.

Current Testing Library

• jest
• yeoman-assert
• yeoman-test

Ready to ditch these libraries for other the commit covers more and efficient testing.

Feature
To add documentation creation library and writing docs for the package.

Library Suggestion

• typedoc
• docsify
• Docusaurus
• documentationjs

Our first Major release will be after completion of this feature.

updated

It would be helpful too if we get improvement on current docs that is on readme(s)

Hi ! 🚀

📄 Goal and about

Currently, this is a simple cli tool for generating web app projects like using MERN stack based on a few questions and some build and development-related questions as well as preferred bundler and all.

Goal. What I want to achieve is a tool that will eliminate the requirement of adding boilerplates manually. the goal extends to a point where I whole adding of boilerplates should be flexible and customizable. As a user I would like to have more options on my bundler or on my styling options, I want a plugin to update my webpack.config.js when I am changing my style loaders or changing my scss to postcss or similar and many other use cases. It will be used as a pair programmer rather than a project generator.

The most important thing about this project will be how plugins are integrating and how they will work. and I consider this as most challenging thing of this project. Plugins will load more than 70% work of using this package. And writing plugins should be simple.

📣 Re-Written of the CLI

Not a new version, its gonna be a new package.

Current Implementation

Currently, the cli is using templates architecture where it is being shipped of the templates while installing which can increase the bundle size of the project and also increase the install time.
We have Three templates right now and have a plane to increase them to more number in future as the goal of this CLI is to become a single app generator for all kind, type, the stack of the project.

New Architecture plan

1. No templates packages in the project core:

• In order to reduce the size and time, no templates are gonna live inside the core package and also not in this repo.
• We are going to adopt the cloning mechanism, and more details about the clone flow will be discussed below or in a separate issue
• Like how gatsby-cli does.

2. Plugin Architecture Most Exciting Plan:

• I have an on-going plan to make it pluggable. These plugins are gonna be separate packages. And each plugin will do a particular set of work.
• Small work like database managing and connecting plugin, Styling managing and creating a plugin, adding passportjs in your project plugin, etc.
• More about these plugin types and how this will be implemented will be discussed in a separate issue.

3. Config file :

• Surely gonna have this config file thing for using the cli as an one more option to use the package.
• A Global Config File system, which is going to have a config file and whenever the cli is running it will load this if CLI finds it!

4. Monorepo:

• The whole project will be a mono repo based project with the core cli logic in the core package. Also, there will core plugins and utility methods in this repo as monorepo.
• Future plans for the GUI version of the cli will be added as monorepo too. Although not sure about this just a thought.

5. Anything to make it FAST:

• This is going to be our main priority. I am ready to compromise additional features in order to make it awesomely fast.
• Planning to have a caching system in order to cache the plugins, packages and also the user's interactions

Working flow not final yet:

1. When starting the cli, you can either pass the Github link to the boilerplate you want to use or the CLI will prompt to ask for it.

   • It will first check for some specific files in the boilerplate project and if it finds it okay to make it customizable and pluggable. then it will install it and will do further work

   • If not, then it will scan the github keywords used in that project and will recommend you based on that keywords. It will try to recommend any default or official boilerplates.

   • command will look similar like this :

     • if passing the boilerplater then may like -b [URL] or if not passing the boilerplate , just
       simply running the CLI , it will start an interactive prompt

2. Work of the Interactive prompt:

   • used will be asked some basic questions like, is it a website with or without server, (basic)

   • then if with the server then chained of questions like server framework or raw? , need a database? if yes then type and preferred ORM for it?. (an advance question which may not be required to answer)

   • Then question for frontends framework, (basic)

   • need state management if supported?, then need SSR if supported?

   • Then language type like TS or JS (an advance question which may not be required to answer)

   • Preferred bundlers, styling thing. (an advance question which may not be required to answer)

   • PWA ? or need minimal alternatives to framework like Preact for react etc.(an advance question which may not be required to answer) ,

3. Using the config file, :

   • May be using flags like -c [path] it will look for global config file if the path is not passed else it will load the config file mentioned in the path
   • then it will use this config file to create the project.

4. Where plugin will come?

   • there will be some default plugins that will be used during the build time like, webpack plugin, or postcss plugin which will be used based on selecting the stack or framework preference. , Like when we select PWA, a PWA managing plugin will be run to handle it.
   • We can say like this. Based on these basic question, the boilerplate project will be selected and Based on the advance question, the plugin will be selected to customize those boilerplates
   • And there will be plugins, which we can add using similar commands like --plugin <plguin-name> inside our project structure and then it will create config file inside the project if not present already, and it will add this plugin name to that config file and then running command like make will run that plugin and also we can prefined plugin(s) in that config file and will run those plugins.

the config file inside the project folder and config file located globally will be different and even with different name ! will have to think about this in details

This is what I got till now !

Enhancement

Improving the CLI with respect to

• Features
• Prettier
• Bug fixings
• Better Questions
• Code Refactor

Even Ready to ditch yeoman-generators if commit consists of better performance and efficient code