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

Organize source files into more directories #137

Merged
merged 2 commits into from
Nov 5, 2022

Conversation

hurrymaplelad
Copy link
Contributor

@hurrymaplelad hurrymaplelad commented Oct 23, 2022

Depends on #135.

This one's subjective, feel free to reject.

I noticed 3 things while working on #135:

  1. Lots of files are duplicated.
  2. Lots of crypto code is duplicated.
  3. There are several different deploy targets all sitting in the root.

I believe the directory shuffling in this PR sets us up to improve all three.

Re 1: #135 already removes the duplicate files committed to cli/, but it required listing all the copies in both build.sh and .gitignore. These changes remove the need for any copies for the cli.

Re 2: We should be setup to use the cli's templating to inline the duplicated code into www. I'll explore this in another PR.

Re 3: I'm optimistic that the cli/, www/ and example/ directories will make the different targets clear and keep them relatively isolated.

@robinmoisson
Copy link
Owner

robinmoisson commented Oct 30, 2022

Thanks @hurrymaplelad! Agreed that splitting things into directory will make things clearer, and allow for deduplicating the encryption code which is needed to support webcrypto without it being a pain to maintain (and would be generally nicer).

I like the suggestions here. A couple a things come to mind:

  • github pages look for an index.html file in either the root directory or a /docs directory. I'd rather not customize that and keep with the default way of doing things on Pages - so index.html would need to stay at the root I think (having a docs/ folder could work but the naming doesn't make much sense)
  • it'd be nice to have all logic related to serving the website self-contained in a www/ folder, but we have this index.html that needs to be out, and since we need to commit the password_template.html and example_encrypted.html files to the repo so github pages can serve it we can either
    • serve them from their own directory (but then we serve stuff outside of www/)
    • or duplicate them into www/ during build, but we need to commit them still so github pages can see it, so we have duplicated files committed and that can be confusing

So one idea is to:

  • put index.html at the root of the repo - paradigm is: the website is the whole repo (not just www/), and can call to any file existing in the repo by its full path
  • remove the www/ directory, and delete kryptojs-3.1.9-1-lib.js
  • move the cli/crypto-js.min.js to lib/kryptojs-3.1.9-1.min.js and use that file both in the CLI and the website
  • add the following mention to the top of the minified KryptoJS file so people can easily check we haven't tampered with it:
/**
 * Crypto JS 3.1.9-1
 * Copied as is from https://cdnjs.cloudflare.com/ajax/libs/crypto-js/3.1.9-1/crypto-js.min.js
 */

What do you think?

@hurrymaplelad
Copy link
Contributor Author

hurrymaplelad commented Nov 1, 2022

Thanks for taking a look!

I usually use a separate gh-pages branch for github pages, and commit a built subdirectory to the root of that branch it using a script like https://github.com/hurrymaplelad/stage-to-branch/blob/main/stage_to_branch. Using github actions, this can happen automatically on every commit to main.

This is definitely more overhead, so you're approach of keeping index.html at the root works for me if you prefer!

@hurrymaplelad
Copy link
Contributor Author

Alrighty @robinmoisson - 729d8c2 should be pretty close to what you described:

  • Moves index.html back to the root.
  • Moves the minified cryptojs to lib/ and updates all refernces.

I got rid of the www/ dir entirely since there was so little left in it, and just reference lib/ and example/ directly to keep things simple.

Copy link
Owner

@robinmoisson robinmoisson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great to me, thank you for the quick iteration! I'm merging. 🙂

@@ -1,11 +1,8 @@
# Usage: `npm run build`
# NPM establishes a reliable working directory
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious - what do you mean by that line ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question!

If you've tried using relative paths in bash scripts, then you've probably seen discussions like
https://stackoverflow.com/q/59895 and http://mywiki.wooledge.org/BashFAQ/028.

It's notoriously tricky to get this right. However, npm run provides some useful extra guarantees - it always executes the script with the working directory set to the directory that contains package.json, regardless of which subdirectory npm run was executed from.

That's why I didn't include a #! /bin/bash or similar, and instead recommended npm run.

Does that make sense?

@robinmoisson robinmoisson merged commit bdc831d into robinmoisson:main Nov 5, 2022
@hurrymaplelad hurrymaplelad deleted the aph-dirs branch November 9, 2022 17:22
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

Successfully merging this pull request may close these issues.

2 participants