Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How can we improve mhy? #15

Open
bafxyz opened this issue Aug 20, 2019 · 3 comments
Open

How can we improve mhy? #15

bafxyz opened this issue Aug 20, 2019 · 3 comments

Comments

@bafxyz
Copy link

bafxyz commented Aug 20, 2019

I'm thinking about using mhy for myself, but i don't like few things:

  • the list of dependencies is huge, and beside babel, ts, webpack and react i don't need others (so i would love to have something like search with autocomplete here) or some presets with checkboxes, i see what https://www.npmjs.com/package/inquirer has good menu constructors with autocomplete.

  • i don't think what it's a good idea to update packages.json all the time when the new version of some package is updated, i guess it should just fetch the latest versions with npm install if we not specifying the special one

  • when the port is busy i recommend to search for free one with something like this https://www.npmjs.com/package/get-port

@wintercounter what do you think about this?

@wintercounter
Copy link
Owner

Thanks for the suggestions. There are definitely several areas for improvements.

For the dependency issues I already have similar solution in mind in the form of presets and keeping mhy to be a thin client but it needs a lot of changes.

One of mhy's mission is making the tools work well together using the latest versions. Installing the latest versions automatically won't guarantee that the tools will work together. For example ESLint 6 is out but they have some radical changes which broke how several other projects and mhy was using it. Having the latest installed automatically would break all tools in mhy.

mhy is basically running the command's of the respective tool. For example when you run mhy wds you basically run webpack-dev-server --config=mhy/configs/webpack. This means an additional workflow has to be implemented for every process that might use a port and IF port !== default AND occupied THEN change config to another port. What I mean is that port allocation is not directly done by mhy. Also this method rises another concern: when there is an issue with mhy and a process doesn't closed correctly for some reason, instead of killing the previous zombie process you end up running more zombie processes on more ports... But there are some workarounds to prevent this, exit if too many times free port not found for example.

Btw for dependency management I've added some tooling that will help you manage dependencies coming from mhy, but it's not finished yet.

@bafxyz
Copy link
Author

bafxyz commented Aug 20, 2019

We can have a config for specific projects like airbnb or whatever, with json of packages which you need for this project and if it's needed the version can be specified in this config. It should solve issues like eslint has now.

@bafxyz
Copy link
Author

bafxyz commented Aug 20, 2019

And yes, it should be tiny with dependencies, that's the main concern which everyone has i guess using it, because everyone has it's own lovely set of packages, so if you have a good idea how can we implement this i would be love to help.

@wintercounter wintercounter changed the title Discussion, how can we improve mhy How can we improve mhy Aug 23, 2019
@wintercounter wintercounter pinned this issue Aug 23, 2019
@wintercounter wintercounter changed the title How can we improve mhy How can we improve mhy? Aug 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants