anstosa / ferry.fyi

A better tracker for the Washington State Ferry System
https://ferry.fyi
GNU General Public License v3.0
11 stars 3 forks source link

Update README.md with local development instructions #24

Closed srt4 closed 5 years ago

srt4 commented 5 years ago

Wanted to check this out and run it locally to see how it works, trying to create a similar UI for work shuttle arrivals. Ran into a few issues, following the README instructions verbatim:

  1. Font Awesome token is missing

    1. This is expected, since it's a secret. However, local development instructions can include that this value needs to be replaced in .npmrc. Alternatively, I have commented out all dependencies for Font Awesome to get around this issue.
  2. npm run server doesn't seem to be a command that works. I get this response, after running brew update && brew upgrade npm && npm update && npm install:

    $ npm run server
    npm ERR! missing script: server
    npm ERR! 
    npm ERR! Did you mean this?
    npm ERR!     worker

    It looks like the corresponding run command should be web, if my understanding is correct.

  3. There's a PostgreSQL server which needs to be running, defined in server/lib/db.js#8:

    const [, dialect] = process.env.DATABASE_URL.match(/^(\w+):\/{1,2}(.*)$/);
    1. I'm going to try to run this against an empty database instance, but I'm not sure if schema provisioning is required for this to work. Since there's a server/migrations and server/model folder I'm thinking it will create the necessary tables.

Let me know if there's anything I missed in getting my environment up and running. I'm happy to submit a PR for items 1 and 2 if the workarounds make sense. Still looking into 3.

anstosa commented 5 years ago

Hi Spencer! Hope all is well with you.

Yeah the README.md was totally out of date. I just made a commit to fill in all the gaps I think. Give that a shot and let me know if it works!

srt4 commented 5 years ago

Thanks for getting back. That got me mostly up and running with a local stack.

I'm now able to, e.g., run curl http://localhost:4040/api/schedule/5/14 and get a correct response.

Seems there is an issue with the UI, though, as I'm seeing this in the console:

:4040/client.js?__WB_REVISION__=a0067af6a6a74512d8fd:38008 Warning: React.createElement: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: object. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.

warningWithoutStack @ :4040/client.js?WB_REVISION=a0067af6a6a74512d8fd:38008 :4040/client.js?WB_REVISION=a0067af6a6a74512d8fd:36430 Uncaught Invariant Violation: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports. at http://localhost:4040/client.js?__WB_REVISION__=a0067af6a6a74512d8fd:36430:34

Will take a look into if there's anything obviously wrong, but this also would probably fall under a separate issue.

anstosa commented 5 years ago

Weird, I can't reproduce that, even in a freshly cloned repo. Any errors in the 3 terminal processes (especially client)?

Are you in Chrome? I do have sourcemaps configured so I'm surprised it's not resolving it in the JS error

srt4 commented 5 years ago

I've tried it in Firefox 69.0.2 and Chrome 77.0.3865.120. The only thing I'm thinking which may cause this is I've attempted to remove the Font Awesome dependencies. Have attached a patch of those changes.

All of the three npm run processes are running with no errors logged. I'll see if I can figure out what's happening with the sourcemaps

remove-fontawesome-patch.txt

srt4 commented 5 years ago

From what I can tell, on my environment, it seems like the result of import App from './App in index.js is not working correctly.

The warning was occurring on index.js with the React.createElement(app) call. Added a log statement above that to print what App was, and it looks to just be an empty object.

anstosa commented 5 years ago

Super weird... I don't know what's going on there. It works fine for me and the code looks correct by inspection. I'd say that sounds like a babel version mismatch issue but the babel version should be locked by package-lock.json...

srt4 commented 5 years ago

I tried this on a new DigitalOcean droplet and it's working perfectly. Definitely something mismatched on my local environment, so I'll probably go through reinstalling node/npm/etc.

Thanks for helping look into this

anstosa commented 5 years ago

Phew, glad I'm not crazy and you got it working

srt4 commented 5 years ago

Oddly, I'm having the exact same issue on a separate OS X environment (with a fresh npm, node, postgres, redis install). This time the sourcemaps show up in the trace, fortunately.

When running this locally, are you using a Linux environment?

For reference:

$ npm --version
6.11.3
$ node --version
v12.12.0
$ sw_vers -productVersion
10.15
anstosa commented 5 years ago

Ah interesting, I guess there could be some subtle platform-specific issue with a dependency? I'm running it in Ubuntu (via WSL) locally

$ npm --version
6.9.0
$ node --version
v10.16.0
$ lsb_release -d
Description:    Ubuntu 16.04.6 LTS
srt4 commented 5 years ago

I think there must be something going on with how webpack is behaving on Mac. I downgraded to node 10.16.0, and npm 6.9.0, deleted node_modules, reran npm install, and still am facing the issue.

What I did notice is that when I build this on Ubuntu, client.js has over twice as many LOC as when I build it on Mac. When I started looking at the diff, it seems the artifact built on Ubuntu is bringing in dependencies while the version built on Mac is not. Very strange.

It may be more than a platform specific issue with a dependency. Going to check if I can get more verbose output from webpack.

To compare:

$ wc -l *
   78939 clientLinux.js
   35074 clientMac.js

Will post more as I find it.

srt4 commented 5 years ago

I finally got to a workaround, but I don't know why it's working this way.

Comparing the webpack output from Ubuntu vs Mac:

Mac

Entrypoint main = main.css client.js
[./client/App.scss] 39 bytes {main} [built]
[./client/index.js] 1.18 KiB {main} [built]
[./node_modules/webpack/buildin/global.js] (webpack)/buildin/global.js 472 bytes {main} [built]
    + 320 hidden modules

Ubuntu

Entrypoint main = main.css client.js
[./client/App.jsx] 2.77 KiB {main} [built]
[./client/Header.jsx] 9.27 KiB {main} [built]
[./client/Menu.jsx] 6.88 KiB {main} [built]
[./client/Schedule/Alerts.jsx] 3.55 KiB {main} [built]
[./client/Schedule/Crossing/Crossing.jsx] 4.66 KiB {main} [built]
[./client/Schedule/Footer.jsx] 7.45 KiB {main} [built]
[./client/Schedule/Schedule.jsx] 11.1 KiB {main} [built]
[./client/Splash.jsx] 3.43 KiB {main} [built]
[./client/app.scss] 39 bytes {main} [built]
[./client/index.js] 1.18 KiB {main} [built]
[./client/lib/Analytics.jsx] 1.58 KiB {main} [built]
[./client/schedule.js] 276 bytes {main} [built]
[./client/terminals.js] 3.87 KiB {main} [built]
[./node_modules/webpack/buildin/global.js] (webpack)/buildin/global.js 472 bytes {main} [built]
[./node_modules/webpack/buildin/module.js] (webpack)/buildin/module.js 497 bytes {main} [built]
    + 413 hidden modules

Missing from the Mac output is App.jsx and all of its dependencies.

So, I suspect there's some existing module or reserved word (?) that's causing it to import another App. Renaming the class to Application and importing it as such got my local environment up and running.

anstosa commented 5 years ago

Super weird... Well thanks for reporting back! Let me know how your project goes