Organize source files into more directories

[hurrymaplelad]

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]

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]

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]

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.

[robinmoisson]

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

[robinmoisson]

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

[hurrymaplelad]

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?