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

As a user I would like auto detection of pages and template directories #3

Closed
1 of 5 tasks
thescientist13 opened this issue Mar 26, 2019 · 1 comment · Fixed by #26
Closed
1 of 5 tasks

As a user I would like auto detection of pages and template directories #3

thescientist13 opened this issue Mar 26, 2019 · 1 comment · Fixed by #26
Assignees
Labels
enhancement Improve something existing (e.g. no docs, new APIs, etc) v0.1.0
Projects
Milestone

Comments

@thescientist13
Copy link
Member

thescientist13 commented Mar 26, 2019

Type of Change

  • New Feature Request
  • Documentation / Website
  • Improvement / Suggestion
  • Bug
  • Other (please clarify below)

Summary

Currently Greenwood is only aware of templates and pages in its own project. Not very helpful, obviously. The project should auto detect basic directories for the user and use the source files in those directories instead.

Details

Currently Greenwood knows of these directories

pagesDir: path.join(__dirname, './templates/'),
scratchDir: path.join(process.cwd(), './.greenwood/'),
templatesDir: path.join(__dirname, './templates/'),
publicDir: path.join(process.cwd(), './public')

What it should do instead

  1. Is "auto-detect" these directories first
    • pagesDir - src/pages/
    • templatesDir - src/templates
  2. Handle page as default template type
  3. Should error gracefully with nice user feedback, e.g
    • "It looks like you don't have a <app|page> template defined. Please include a simple example like this in <src/ ex. sample code here"
    • "It looks like you don't
  4. Greenwood should "own" index.html, we will make it more configurable in other tasks.
  5. Write tests
  6. Update README docs to demonstrate this new feature
@thescientist13 thescientist13 added the enhancement Improve something existing (e.g. no docs, new APIs, etc) label Mar 26, 2019
@thescientist13 thescientist13 added this to the MVP milestone Mar 26, 2019
@thescientist13 thescientist13 added this to TODO in 1 Mar 27, 2019
@hutchgrant hutchgrant self-assigned this Mar 28, 2019
@hutchgrant
Copy link
Member

hutchgrant commented Mar 28, 2019

There's a major problem with doing this that we need to tackle.

An app(or page)-template.js could(probably will) include additional components, such as a header, footer, sidebar, who knows. When they import those components, lets say we force them to use a standard folder, for example src/components okay all the components go in there. Fine.

But... when we build, it needs to copy those files over to the scratchDirectory. This is where the problem begins.

so my user example project could be

├── src
│   ├── components
│   │   └── index.js
│   ├── pages
│   │   └── hello.md
│   └── templates
│       ├── app-template.js
│       └── page-template.js

so the app-template.js if it wants to include the components, it needs to:

import '../component/index.js`

No problem right?

Well, the problem is when this app-template turns into a app.js file within the .greenwood scratch directory, no components folder exists and if we create it, it still won't be the correct path for the relative import above.

import './components/index.js`

works, but that's so anti-practise.

edit: actually came up with a small solution. the app.js file must be placed in any directory so that the relative import paths (whatever they are) at least are correct. So I'm putting the app.js into a .greenwood/app/app.js directory and modifying webpack entry point. I'll also put the list.js (which is also broken by this path change) in that app directory as well by default.

@hutchgrant hutchgrant moved this from TODO to IN PROGRESS in 1 Mar 28, 2019
@hutchgrant hutchgrant moved this from IN PROGRESS to IN REVIEW in 1 Mar 28, 2019
@thescientist13 thescientist13 moved this from IN REVIEW to DONE in 1 Mar 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improve something existing (e.g. no docs, new APIs, etc) v0.1.0
Projects
No open projects
1
DONE
Development

Successfully merging a pull request may close this issue.

2 participants