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

Rebuild the Site #2039

Merged
merged 168 commits into from
Feb 12, 2019
Merged

Rebuild the Site #2039

merged 168 commits into from
Feb 12, 2019

Conversation

skipjack
Copy link
Collaborator

@skipjack skipjack commented Apr 14, 2018

This PR is a complete refactor of the site's build process using pure webpack. It offers...

  • Much faster build times (~30s).
  • More PWA features (e.g. the site now acts like an SPA once entered).
  • Various code simplification and cleanup.

I let this branch get a little too big with not enough visibility. This PR should remedy the visibility part and start us on a path to get it wrapped up in the next few weeks so we can go back to focusing on content. Here's what's left:

Nice to haves (won't be blockers for release and can be tackled after merge):

  • Preload bundles for future navigation
  • Improve path array scrapping for page title population
  • Gather data metrics of current site on different sections for later comparison with rebuilt version (@jeremenichelli)
  • Improve font loading strategy (@jeremenichelli)
  • Replace font icons with SVGs (@jeremenichelli)

No more work should be done on this branch directly. Please open PRs directed towards rebuild to hit these TODOs.

This work is heavily related to #1525 and #1400. Once this is merged we should probably close both those tickets and make more targeted tickets/prs for anything else that remains. I think this also closes #2018 and probably a few other tickets. With the introduction of remark-mermaid, it makes #469 finishable. Please comment if you know of other tickets this might resolve.

MagicDuck and others added 30 commits February 6, 2018 23:19
This is still very much a work in progress but essentially my plan is to use
the `webpack`, along with the following plugins, to generate the site...

- DirectoryTreePlugin: Creates a JSON representation of `src/content` for navigation and `import()`
- StaticSiteGeneratorPlugin: Creates HTML files in `/dist` for all markdown pages
- RedirectPlugin: Generates redirects in a similar manner to antwar (?)
- And then any of the standard plugins...

This rewrite also means the site would be both an SPA as well as a static
site and should make finishing the PWA ticket much easier. More to come...
The 	`react-banner` package was built based off of this component
but has a few fixes and will externalize any bugs so this site can
focus more on content. It also allows anyone else to utilize the banner
in other sites.

Still a few `TODO`s left...
Move font import to css and remove what's already or will be
accounted for by other parts of the site (e.g. there's already a
`TODO` for re-integrating `docsearch`).
Not sure the `fontantialias` mixing will be necessary if we update the inline
`svg` elements/icons.
…d respond to `open` prop

More refactoring to come (as hinted by the `TODO`s)...
Pick up new `_content.json` file and start using it for both routing as
well as navigation building. Also, maintain `mobileSidebarOpen` state
and toggle method for a more standard react approach.
This replaces the previous need for the `yarn-lock.json`.
Had this commented out initially while testing the `SSGPlugin` out
but it doesn't seem to cause any issues.
This allows simpler and more straightforward usage within a react-based
application.
…data structure

Utilize the new `Markdown` component and `page` structure to simplify the
`Page` and `PageLink` code.
Note that there's still some work to be done here...

- We need to exclude `src/content` from the main bundle.
- We need to implement `import()` for the browser level.
- Still much more to fix/re-implement in terms of routes and content.

That said, the build is much faster (though we need to work on rebuild
speed using a more targeted rebuild). Getting there...
@montogeek
Copy link
Member

Update regarding #2039 (comment)
Once #2564 is merged, we can merge this branch.

@EugeneHlushko
Copy link
Member

Need to look why travis failing tho

@EugeneHlushko
Copy link
Member

The links linter is still failing, and if i understand correctly:

  • you had opened a PR to fix external MD file that fails to lint
  • next time external .md file gets changes, there is change our build stops working

Please correct me if i am wrong @Munter

@Munter
Copy link
Collaborator

Munter commented Jan 15, 2019

@EugeneHlushko Consistently problematic external dependencies, like badges, which have shown instability, can be marked as --skip or --todo in hyperlink, which allows us to either not to the test at all for a url, or accept an error on a url.

The problem here was, there was no url at all, see webpack-contrib/cache-loader#60

That triggered what I would call a bug in html-loader, which means there was no real URL to match against for a --skip or --todo pattern: webpack-contrib/html-loader#191

But yes, it is correct that our CI internal link check ha dependencies on each of the README's of the included loaders and plugins being correct.

@EugeneHlushko
Copy link
Member

EugeneHlushko commented Jan 15, 2019

Maybe this is not the right way to go about it? Could be that doing checks on the links that this repo owns in ./src/**/*.md makes more sense to do before fetching external content?

@Munter
Copy link
Collaborator

Munter commented Jan 15, 2019

It's still content shown on the docs page. I found so many broken references across pages in the docs, missing images, wrong fragment identifier links etc during the work in this branch. It seriously difficult to make sure everything works correctly and gives the best user experience if you don't have tooling to make sure of it.

We just need to balance it out so there are no false negatives blocking the build. Like the last travis run here for example. I'll add an accepted failure on that one

@EugeneHlushko
Copy link
Member

I think that our cd is at risk with this tho as i pointed out earlier, if the rest of maintainers are happy to deal with that, lets leave it as you implemented - to check externally fetched md files too

@EugeneHlushko
Copy link
Member

EugeneHlushko commented Jan 24, 2019

Let's ping maintainers again for final look since no one responded and merge in X days if no additional feedback is given. This is a huge change that everyone had worked hard on and waited for.

cc @jeremenichelli @skipjack @montogeek @Munter

UPD: close and open was accidental lol, gh buttons too close for my phat fingers.

@skipjack
Copy link
Collaborator Author

Awesome to see this finally moving forward again, thanks to those that revived it. I’d love to help more but am still very strapped for time.

If I remember correctly, it was only one or two markdown parsing issues that were blocking the merge. Based on the other comments/merges, it sounds like those are resolved so from my standpoint this is good to go. If we notice anything after the merge I’ll try to find some time to help out.

@montogeek
Copy link
Member

montogeek commented Jan 24, 2019

@skipjack It is always nice hearing from you. Yes, it is ready but we haven't found or schedule the time to do it.
We need to find some time, maybe this Saturday?
@EugeneHlushko and anybody else interested, feel free to DM me on Slack

@Munter
Copy link
Collaborator

Munter commented Jan 24, 2019

I should be able to help out Saturday in case things explode

# Conflicts:
#	src/content/configuration/index.md
#	src/content/configuration/resolve.md
#	yarn.lock
@EugeneHlushko EugeneHlushko merged commit 4a24a1e into master Feb 12, 2019
@EugeneHlushko
Copy link
Member

Lets see how it goes... 🤞

@jeremenichelli
Copy link
Member

OMG IT'S HAPPENING

@EugeneHlushko
Copy link
Member

Its live!

@EugeneHlushko EugeneHlushko deleted the rebuild branch February 12, 2019 16:30
@jeremenichelli
Copy link
Member

Kudos on everyone involved, it's working like a charm <3

@skipjack
Copy link
Collaborator Author

Yeah just poked around a bit, seems stable. Tested navigating through a variety of sections and searching, all seemed to work fine. The only thing I'm noticing, which is definitely not critical, is that the sidebar only sticks for a little bit and then floats up with the rest of the page on scroll. Probably a little css tweak required there.

I checked the console and the only errors I'm seeing are images.opencollective 404s on the landing page (which I think are to be expected).

@montogeek
Copy link
Member

@EugeneHlushko Nice!

@Munter
Copy link
Collaborator

Munter commented Feb 12, 2019

Awesome!!!

Since we also eliminated the continuous github API polling on this branch, we can now turn off the Travis parallel run limitation that we had previously imposed. That should cut roundtrip time for feedback on PR builds down by quite a lot combined with the already shorter build times

-- edit --
Looks like I had access to that. I switched the limit of 1 concurrent job on Travis off. I think that gives us the default of 4 concurrent if I recall correctly

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

Successfully merging this pull request may close these issues.

Build time is insufferably long