build output has no styles, JS bundle is 404

[winkler1]

Is there supposed to be a .js? This is "doubly static", right?

[bebraw]

Is there supposed to be a .js? This is "doubly static", right?

Yeah .js is expected. We generate a HTML file per each page. Besides that there is react-router based routing system that kicks in when JavaScript is enabled. This means that after initial loading of the page it will treat the site like a single page app (navigation via HTML5 History API).

@eldh can probably comment more on this.

[winkler1]

Ah OK. That's cool - for better runtime perf. It'll fetch MD files and transform on the fly? Given the Brad Denver influence / "static site generator", expected fully static HTML. Would be good to clarify that.

This seems like the value prop-

Pros:

• fast user experience
• SEO indexable
• No special server requirements for wildcarding urls
• Familiar for ReactJS fans

Cons

• Not just precomputed static files. runtime JS could have bugs, greater complexity/surface area.

[bebraw]

It'll fetch MD files and transform on the fly?

The current build is just static HTML. No transformation. It's heavily based on Denver's approach.

The whole `react-router´ + routing using that etc. is something that's one of the goals here. Ideally we want both. And there's the whole isomorphic server idea...

[eldh]

I haven't seen the 404 on main-bundle.js before though. Will see if I can reproduce somehow.

[bebraw]

@winkler1 Keep in mind that build and develop output are two separate things. Currently build output is just static whereas latter contains the JavaScript needed for HMR to work. Over longer term these two will likely converge a bit.

[winkler1]

Is this high priority? IMO, having functional output is essential for an MVP. It's not viable with broken css and script tag output. I'm probably crazy, but want to use it for a blog on rrocks, have a post waiting :)

[eldh]

I haven't put a bunch of time on it, but haven't been able to reproduce. Will look into it more soon. It's definitely something we need to fix for an MVP!

[bebraw]

@eldh This is related to the minimal boilerplate somehow. I have actually seen the same.

[eldh]

ah, ok. I'll have a closer look after I've done the processPages hooks.

[winkler1]

Thanks guys! This script repros it for me. It's good IMO because it's a fresh start from published sources--

npm install antwar-cli -g

rm -rf antwar_test_blog
antwar --init antwar_test_blog
cd antwar_test_blog

echo 'INSTALLED VERSION'
npm list -g antwar
antwar --build
tree build # "brew install tree"
cd build
python -m SimpleHTTPServer

tree build gives this. No JS to be seen:

$ tree build
build
├── assets
│   ├── img
│   │   └── images_go_here.md
│   └── main.css
├── blog
│   ├── a-draft
│   │   └── index.html
│   ├── first-post
│   │   └── index.html
│   ├── index.html
│   └── second-post
│       └── index.html
├── index.html
└── page
    └── index.html

It'd be cool to hook something like that up to phantom as a smoke test looking for script errors, visual diffs etc. Something like https://github.com/chenglou/node-huxley. There must be lots of moving parts to all this...

[bebraw]

It'd be cool to hook something like that up to phantom as a smoke test looking for script errors, visual diffs etc. Something like https://github.com/chenglou/node-huxley. There must be lots of moving parts to all this...

Yeah, lots of moving parts. I guess the most ghetto way to do this would be to set up a Travis script. Here's a deployment script to give you some idea: https://gist.github.com/domenic/ec8b0fc8ab45f39403dd .

In other words we could set up a script to execute the right commands and then assert the output somehow. If something fails, echo something nice and hit exit 1.

[eldh]

Pushed 0.3.6, should hopefully fix this issue. Let me know otherwise!

[winkler1]

Looks good!

[eldh]

I was a bit quick, this version broke antwar -d. New version coming up.

[eldh]

0.3.7 published.