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

Derive the output directory of a web project repo #91

Open
lukejacksonn opened this issue Apr 3, 2017 · 4 comments
Open

Derive the output directory of a web project repo #91

lukejacksonn opened this issue Apr 3, 2017 · 4 comments

Comments

@lukejacksonn
Copy link

The norm for web based projects (that employ a build pipeline at least) is that there are src files that get built into an output directory.. there is no established naming convention for such output directories although there are some common names:

  • dist
  • build
  • www
  • out

I would love a script that does its best to derive the name of the output directory containing the distributed files.. ideally before a build has happened.

I realise this operation is never going to be fully deterministic.. but I know that the problem can be tackled procedurally by human with a good degree of accuracy. Some pointers can often be found by:

  • Examining the README.md
  • Examining the package.json namely the build script task
  • Examining the gulp or grunt file
  • Examining the .gitignore
  • A combination of one or more of the above
@sindresorhus
Copy link
Owner

sindresorhus commented Apr 3, 2017

What problem are you trying to solve with this? In what situation would you use this?

@lukejacksonn
Copy link
Author

I have an electron app.. you input a repo url https://github.com/lukejacksonn/malette for example. It proceeds to:

  • git clone <input_url> apps/<repo_fullname>
  • npm install
  • npm run build
  • http-server-spa apps/<repo_fullname>/<output_dir>

image

Without knowing the resultant <repo_fullname>/<ouput_dir> the best I can do is only support apps that build into a specific directory (say build or dist) or have the output directory explicitly stated in the project package.json. Both of these approaches demands the developer adhere to some level of conformity.

I don't want to impose anything on the developer and at the same time I would like to support as many apps as possible, out of the box so to speak.

An optimistic (but still naive) approach I took was to go through the common list of output directory names and check if the said directory exists in the apps/<repo_fullname>/ folder. If one exists then go ahead and serve the contents of that directory (works a good percentage of the time).

I just know that there is a better approach and despite it's impure nature, I thought it might be your type of problem 💯 (again, I am aware of the fact there there really is no way of guaranteeing a correct answer and that this problem is very domain specific, sorry).

Even something like comparing the directory structure before and after npm run build happens might suffice and if that is truly the simplest way of deriving the output directory then so be it!

@sholladay
Copy link

I built a whole suite of modules to make build output and their paths more deterministic and standardized. See build-dir and friends.

I could probably make some kind of adapter that would funnel builds from other systems into a well-known location created by build-dir. Then you would always be able to access the build via <cwd>/latest-build, which would be a symlink pointing to a versioned directory.

I think a directory diff before & after npm run build, as you suggest, is a solid start. We would need to be mindful of projects which, for better or worse, commit their builds to the repository. It's unusual, but some people do it. In that case, there would potentially be no new files or directories created as immediate children of the project directory.

@lukejacksonn
Copy link
Author

@sholladay that sounds awesome! I still haven't made any attempt to resolve the issue myself, if you take a stab at it keep me posted. If it works I will happily resurrect the project mentioned above and try it out 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants