allow dcs paths to be deeper than one folder

Author: pngwn

dist/main.js

@@ -1621,6 +1621,21 @@ function is_empty(obj) {
 	return JSON.stringify(obj) === JSON.stringify({});
 }
 
+function find_folder(
+	files,
+	paths,
+	index = 0
+) {
+	if (!Array.isArray(files.content)) return false;
+
+	const segment = files.content.find((v) => v.name === paths[index]);
+
+	if (!segment) return false;
+	if (paths[index + 1] === undefined) return segment;
+
+	return find_folder(segment, paths, index + 1);
+}
+
 function transform_files(
 	file,
 	pkg_path,
@@ -1632,33 +1647,33 @@ function transform_files(
 	const base_docs = {};
 	const pkgs = [];
 
-	if (file.is_dir && Array.isArray(file.content)) {
-		file.content.forEach(({ name, content }) => {
-			if (name === docs_path && Array.isArray(content)) {
-				is_docs = true;
-				content.forEach((docs) => {
-					if (!doc_types.includes(docs.name) || !Array.isArray(docs.content))
-						return;
+	const docs_folder = find_folder(file, docs_path.split("/"), 0);
+	const pkg_folder = find_folder(file, pkg_path.split("/"), 0);
+
+	if (docs_folder && Array.isArray(docs_folder.content)) {
+		is_docs = true;
+		docs_folder.content.forEach((docs) => {
+			if (!doc_types.includes(docs.name) || !Array.isArray(docs.content))
+				return;
+
+			base_docs[docs.name ] = docs.content.map((entry) =>
+				strip_meta(entry.name, entry.content)
+			);
+		});
+	}
 
-					base_docs[docs.name ] = docs.content.map((entry) =>
+	if (pkg_folder && Array.isArray(pkg_folder.content)) {
+		pkg_folder.content.forEach((docs) => {
+			if (!Array.isArray(docs.content)) return;
+
+			pkgs.push([
+				docs.name,
+				{
+					docs: docs.content.map((entry) =>
 						strip_meta(entry.name, entry.content)
-					);
-				});
-			}
-			if (name === pkg_path && Array.isArray(content)) {
-				content.forEach((docs) => {
-					if (!Array.isArray(docs.content)) return;
-
-					pkgs.push([
-						docs.name,
-						{
-							docs: docs.content.map((entry) =>
-								strip_meta(entry.name, entry.content)
-							),
-						},
-					]);
-				});
-			}
+					),
+				},
+			]);
 		});
 	}
 

src/fs/fixtures/full_docs.ts

@@ -3,7 +3,7 @@ import * as path from "path";
 import { rc_read_file } from "../get_content";
 
 const base_path = path.join(process.cwd(), "src", "fs", "fixtures");
-const repo_names = ["repo-1", "repo-2", "repo-3"];
+const repo_names = ["repo-1", "repo-2", "repo-3", "repo-4"];
 
 async function run() {
 	const repos = await Promise.all(

src/fs/fixtures/generateFixtures.ts

@@ -0,0 +1,55 @@
+---
+title: Frameworks without the framework: why didn't we think of this sooner?
+description: You can't write serious applications in vanilla JavaScript without hitting a complexity wall. But a compiler can do it for you.
+author: Rich Harris
+authorURL: https://twitter.com/Rich_Harris
+---
+
+> Wait, this new framework has a *runtime*? Ugh. Thanks, I'll pass.
+> **– front end developers in 2018**
+
+We're shipping too much code to our users. Like a lot of front end developers, I've been in denial about that fact, thinking that it was fine to serve 100kb of JavaScript on page load – just use [one less .jpg!](https://twitter.com/miketaylr/status/227056824275333120) – and that what *really* mattered was performance once your app was already interactive.
+
+But I was wrong. 100kb of .js isn't equivalent to 100kb of .jpg. It's not just the network time that'll kill your app's startup performance, but the time spent parsing and evaluating your script, during which time the browser becomes completely unresponsive. On mobile, those milliseconds rack up very quickly.
+
+If you're not convinced that this is a problem, follow [Alex Russell](https://twitter.com/slightlylate) on Twitter. Alex [hasn't been making many friends in the framework community lately](https://twitter.com/slightlylate/status/728355959022587905), but he's not wrong. But the proposed alternative to using frameworks like Angular, React and Ember – [Polymer](https://www.polymer-project.org/1.0/) – hasn't yet gained traction in the front end world, and it's certainly not for a lack of marketing.
+
+Perhaps we need to rethink the whole thing.
+
+
+## What problem do frameworks *really* solve?
+
+The common view is that frameworks make it easier to manage the complexity of your code: the framework abstracts away all the fussy implementation details with techniques like virtual DOM diffing. But that's not really true. At best, frameworks *move the complexity around*, away from code that you had to write and into code you didn't.
+
+Instead, the reason that ideas like React are so wildly and deservedly successful is that they make it easier to manage the complexity of your *concepts*. Frameworks are primarily a tool for structuring your thoughts, not your code.
+
+Given that, what if the framework *didn't actually run in the browser*? What if, instead, it converted your application into pure vanilla JavaScript, just like Babel converts ES2016+ to ES5? You'd pay no upfront cost of shipping a hefty runtime, and your app would get seriously fast, because there'd be no layers of abstraction between your app and the browser.
+
+
+## Introducing Svelte
+
+Svelte is a new framework that does exactly that. You write your components using HTML, CSS and JavaScript (plus a few extra bits you can [learn in under 5 minutes](https://v2.svelte.dev/guide)), and during your build process Svelte compiles them into tiny standalone JavaScript modules. By statically analysing the component template, we can make sure that the browser does as little work as possible.
+
+The [Svelte implementation of TodoMVC](https://svelte-todomvc.surge.sh/) weighs 3.6kb zipped. For comparison, React plus ReactDOM *without any app code* weighs about 45kb zipped. It takes about 10x as long for the browser just to evaluate React as it does for Svelte to be up and running with an interactive TodoMVC.
+
+And once your app *is* up and running, according to [js-framework-benchmark](https://github.com/krausest/js-framework-benchmark) **Svelte is fast as heck**. It's faster than React. It's faster than Vue. It's faster than Angular, or Ember, or Ractive, or Preact, or Riot, or Mithril. It's competitive with Inferno, which is probably the fastest UI framework in the world, for now, because [Dominic Gannaway](https://twitter.com/trueadm) is a wizard. (Svelte is slower at removing elements. We're [working on it](https://github.com/sveltejs/svelte/issues/26).)
+
+It's basically as fast as vanilla JS, which makes sense because it *is* vanilla JS – just vanilla JS that you didn't have to write.
+
+
+## But that's not the important thing
+
+Well, it *is* important – performance matters a great deal. What's really exciting about this approach, though, is that we can finally solve some of the thorniest problems in web development.
+
+Consider interoperability. Want to `npm install cool-calendar-widget` and use it in your app? Previously, you could only do that if you were already using (a correct version of) the framework that the widget was designed for – if `cool-calendar-widget` was built in React and you're using Angular then, well, hard cheese. But if the widget author used Svelte, apps that use it can be built using whatever technology you like. (On the TODO list: a way to convert Svelte components into web components.)
+
+Or [code splitting](https://twitter.com/samccone/status/797528710085652480). It's a great idea (only load the code the user needs for the initial view, then get the rest later), but there's a problem – even if you only initially serve one React component instead of 100, *you still have to serve React itself*. With Svelte, code splitting can be much more effective, because the framework is embedded in the component, and the component is tiny.
+
+Finally, something I've wrestled with a great deal as an open source maintainer: your users always want *their* features prioritised, and underestimate the cost of those features to people who don't need them. A framework author must always balance the long-term health of the project with the desire to meet their users' needs. That's incredibly difficult, because it's hard to anticipate – much less articulate – the consequences of incremental bloat, and it takes serious soft skills to tell people (who may have been enthusiastically evangelising your tool up to that point) that their feature isn't important enough. But with an approach like Svelte's, many features can be added with absolutely no cost to people who don't use them, because the code that implements those features just doesn't get generated by the compiler if it's unnecessary.
+
+
+## We're just getting started
+
+Svelte is very new. There's a lot of work still left to do – creating build tool integrations, adding a server-side renderer, hot reloading, transitions, more documentation and examples, starter kits, and so on.
+
+But you can already build rich components with it, which is why we've gone straight to a stable 1.0.0 release. [Read the guide](https://v2.svelte.dev/guide), [try it out in the REPL](/repl), and head over to [GitHub](https://github.com/sveltejs/svelte) to help kickstart the next era of front end development.

src/fs/fixtures/output-repo-3.js

@@ -0,0 +1,60 @@
+---
+title: The easiest way to get started with Svelte
+description: This'll only take a minute.
+author: Rich Harris
+authorURL: https://twitter.com/Rich_Harris
+---
+
+Svelte is a [new kind of framework](/blog/frameworks-without-the-framework). Rather than putting a `<script src='svelte.js'>` tag on the page, or bringing it into your app with `import` or `require`, Svelte is a compiler that works behind the scenes to turn your component files into beautifully optimised JavaScript.
+
+Because of that, getting started with it can be a little bit confusing at first. How, you might reasonably ask, do you make a Svelte app?
+
+
+## 1. Use the REPL
+
+The [Svelte REPL](repl) is the easiest way to begin. You can choose from a list of examples to get you started, and tweak them until they do what you want.
+
+<aside><p>You'll need to have <a href="https://nodejs.org/">Node.js</a> installed, and know how to use the terminal</p></aside>
+
+At some point, your app will outgrow the REPL. Click the **download** button to save a `svelte-app.zip` file to your computer and uncompress it.
+
+Open a terminal window and set the project up...
+
+```bash
+cd /path/to/svelte-app
+npm install
+```
+
+...then start up a development server:
+
+```bash
+npm run dev
+```
+
+This will serve your app on [localhost:5000](http://localhost:5000) and rebuild it with [Rollup](https://rollupjs.org) every time you make a change to the files in `svelte-app/src`.
+
+
+## 2. Use degit
+
+When you download from the REPL, you're getting a customised version of the [sveltejs/template](https://github.com/sveltejs/template) repo. You can skip messing around with zip files by using [degit](https://github.com/Rich-Harris/degit), a project scaffolding tool.
+
+In the terminal, you can instantly create a new project like so:
+
+```bash
+npx degit sveltejs/template my-svelte-project
+cd my-svelte-project
+npm install
+npm run dev
+```
+
+This will create a new project in the `my-svelte-project` directory, install its dependencies, and start a server on http://localhost:5000.
+
+Once you've tinkered a bit and understood how everything fits together, you can fork [sveltejs/template](https://github.com/sveltejs/template) and start doing this instead:
+
+```bash
+npx degit your-name/template my-new-project
+```
+
+And that's it! Do `npm run build` to create a production-ready version of your app, and check the project template's [README](https://github.com/sveltejs/template/blob/master/README.md) for instructions on how to easily deploy your app to the web with [Now](https://zeit.co/now) or [Surge](http://surge.sh/).
+
+You're not restricted to using Rollup — there are also integrations for [webpack](https://github.com/sveltejs/svelte-loader), [Browserify](https://github.com/tehshrike/sveltify) and others, or you can use the [Svelte CLI](https://github.com/sveltejs/svelte-cli) (Update from 2019: with Svelte 3 the CLI was deprecated and we now use [sirv-cli](https://www.npmjs.com/package/sirv-cli) in our template. Feel free to use whatever tool you like!) or the [API](https://github.com/sveltejs/svelte/tree/v2#api) directly. If you make a project template using one of these tools, please share it with the [Svelte Discord chatroom](chat), or via [@sveltejs](https://twitter.com/sveltejs) on Twitter!

src/fs/fixtures/output-repo-4.js

@@ -0,0 +1,78 @@
+---
+title: The zen of Just Writing CSS
+description: I would say this is the future, but we're already doing it.
+author: Rich Harris
+authorURL: https://twitter.com/Rich_Harris
+---
+
+It's fashionable to dislike CSS. There are lots of reasons why that's the case, but it boils down to this: CSS is *unpredictable*. If you've never had the experience of tweaking a style rule and accidentally breaking some layout that you thought was completely unrelated — usually when you're trying to ship — then you're either new at this or you're a much better programmer than the rest of us.
+
+So the JavaScript community rolled up its sleeves and got to work. Over the last couple of years, there's been a Cambrian explosion of libraries aimed at making CSS behave, collectively referred to as *CSS-in-JS*.
+
+What you might not realise is that **the biggest problems with CSS can be solved without CSS-in-JS**. Without those problems, writing CSS isn't just tolerable — it's enjoyable. And you don't have to find solutions to the additional problems that CSS-in-JS introduces.
+
+This article isn't in any way intended as criticism of the hard work the CSS-in-JS community has done. It's one of the most active corners of the JS ecosystem, and new ideas are springing up every week. Instead, my purpose is to illustrate why an alternative approach — based on Single File Components with real CSS — is so damn delightful.
+
+
+## The biggest problem with CSS
+
+Everything in CSS is global. Because of that, styles intended for one bit of markup often end up affecting another. Because of *that*, developers often resort to wild namespacing conventions (not 'rules', since they're very difficult to enforce) that mostly just increase your risk of RSI.
+
+It gets worse when you're working on a team. No-one dares touch styles authored by someone else, because it's often unclear what they're doing, what markup they apply to, and what disasters will unfold if you remove them.
+
+The consequence of all this is the **append-only stylesheet**. There's no way of knowing which code can safely be removed, so it's common to undo some existing style with another, more specific style — even on relatively small projects.
+
+
+## Single File Components change all that
+
+The idea behind SFCs is simple: you write your components in an HTML file that (optionally) contains a `<style>` and `<script>` attribute describing the component's styles and behaviour. Svelte, Ractive, Vue and Polymer all follow this basic pattern.
+
+<aside>
+	<p><a href="blog/frameworks-without-the-framework">Read the introductory blog post</a> if you're new to Svelte. Or <a href="https://twitter.com/padolsey/status/899717303234908160">read</a> <a href="https://twitter.com/sveltejs/status/901818357644701696">the</a> <a href="https://twitter.com/sveltejs/status/901818106309476352">testimonials</a>.</p>
+</aside>
+
+(For the rest of this article we'll be using Svelte, obviously. But if the idea of using a template language makes you shudder — your fears are misplaced, but that's a topic for another day — then just use Vue which lets you use JSX in your SFCs.)
+
+Several wonderful things happen as a result:
+
+* Your styles are *scoped to the component*. No more leakage, no more unpredictable cascade. And no more sesquipedalian classnames designed to prevent conflicts.
+* You don't need to go spelunking through your folder structure to find the rules that are breaking your stuff.
+* The compiler (in Svelte's case) can **identify and remove unused styles**. No more append-only stylesheets!
+
+Let's see what that looks like in practice.
+
+<figure>
+	<video controls poster='https://svelte-technology-assets.surge.sh/just-write-css.jpg'>
+		<source type='video/mp4' src='https://svelte-technology-assets.surge.sh/just-write-css.mp4'>
+	</video>
+
+	<figcaption>
+		Is this what they mean by 'use the platform'?
+	</figcaption>
+</figure>
+
+Every code editor already knows about CSS, so there's a good chance that you'll get autocomplete, linting, syntax highlighting and so on — all without additional JS-fatigue-inducing tools.
+
+And because it's real CSS, rather than some camelCased quotes-everywhere impostor, we can take advantage of the 'tweak in devtools, paste back into our source code' workflow, which I personally couldn't live without. Notice that we get CSS sourcemaps out of the box, so you can instantly pinpoint the lines in question. It's hard to overstate the importance of this: when you're in WYSIWYG mode, you're not thinking in terms of your component tree, so having a robust way to figure out *where these damn styles came from* is essential. Doubly so if someone else originally wrote the component. (I promise you, this is the single biggest productivity boost to your CSS workflow. If you're writing styles without sourcemaps, you are almost certainly wasting a lot of time. I know I was.)
+
+Svelte transforms your selectors (using an attribute that's also applied to affected elements, though the exact mechanism is unimportant and subject to change) to achieve the scoping. It warns on and removes any unused rules, then it minifies the result and lets you write it out to a `.css` file. There's also an experimental new option to compile to web components, using shadow DOM to encapsulate the styles, if that's your jam.
+
+This is all possible because your CSS is parsed (with [css-tree](https://github.com/csstree/csstree)) and statically analysed in the context of your markup. Static analysis opens the doors to all kinds of exciting future possibilities — smarter optimisations, a11y hints — that are much harder if your styles are computed dynamically at runtime. We're just getting started.
+
+
+## But we can add tools to do [x]!
+
+If your reaction to the video was 'fine, but if we use TypeScript and write plugins for each editor then we can get all the autocomplete and syntax highlighting stuff' — in other words, if you believe that in order to achieve parity with CSS it makes sense to build, document, promote and maintain a fleet of ancillary projects — then, well, you and I may never see eye to eye!
+
+
+## We don't have all the answers — yet
+
+Having said all that, CSS-in-JS does point to answers to some lingering questions:
+
+* How can we install styles from npm?
+* How can we reuse constants that are defined in a single place?
+* How can we compose declarations?
+
+Personally, I haven't found these issues to outweigh the benefits of the approach outlined above. You may well have a different set of priorities, and they may be reason enough for you to abandon CSS.
+
+But at the end of the day, you have to know CSS anyway. Love it or loathe it, you must at least *learn* it. As custodians of the web, we have a choice: create abstractions that steepen the web dev learning curve yet further, or work together to fix the bad parts of CSS. I know which I choose.