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.

Sign up for GitHub

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

Jump to bottom

resolve (deeply) nested relative template paths to expected workspace path #435

Closed
1 of 5 tasks
thescientist13 opened this issue Nov 8, 2020 · 3 comments · Fixed by #618
Closed
1 of 5 tasks

resolve (deeply) nested relative template paths to expected workspace path #435

thescientist13 opened this issue Nov 8, 2020 · 3 comments · Fixed by #618
Assignees
@thescientist13
Labels
CLI enhancement Improve something existing (e.g. no docs, new APIs, etc) v0.13.0
Milestone
1.0

Comments

@thescientist13
Copy link
Member

thescientist13 commented Nov 8, 2020 •
edited
Loading

Type of Change

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

Summary

In a user's workspace, given a structure like this

src/
  components/
    header.js
    footer.js
  pages/
    one/
      two/
        three/
          index.md
    index.md
  layouts/
    page.html

Users could reference files in their templates one of two ways

  1. using an "absolute" relative path/
  2. using a "true" relative path ../

Right now, only the first option is supported / documented *

<head>
  <script type="module" src="/components/header.js"></script>
  <script type="module" src="/components/footer.js"></script>
</head>

* Technically the first option is supported but only if you are at 1 level of nesting as ../ can't break out of the web root, but once you go further, you start resolving the path relative to the browser's URL, leading to URLs like this will fail when resolved to the actual filesystem

/one/two/components/header.js

Details

Ideally it would be great if Greenwood could support the ../ as deeply as needed, which would then allow editors and IDEs be able to do the directory resolution and autocomplete for users as well as not breaking path lookups to the workspace.

<head>
  <script  type="module" src="../components/header.js"></script>
  <script  type="module" src="../components/footer.js"></script>
</head>

What is nice about this, is that editors can resolve this for users and do autocomplete lookup, which is really nice. This also aligns with how paths are done in ESM, e.g.

import something from '../utils.js';

Would also be good to resolve / address the following
@thescientist13 thescientist13 added the enhancement Improve something existing (e.g. no docs, new APIs, etc) label Nov 8, 2020
@thescientist13 thescientist13 mentioned this issue Nov 8, 2020
Closed
53 tasks
@thescientist13 thescientist13 mentioned this issue Nov 12, 2020
Merged
12 tasks
@thescientist13 thescientist13 mentioned this issue Dec 22, 2020
Merged
22 tasks
@thescientist13 thescientist13 mentioned this issue Jan 19, 2021
Merged
6 tasks
@thescientist13
Copy link
Member Author

I think as part of #466 , we can now support relative paths at least via the Koa server.

However, for Rollup, we would need to resolve this because this being referenced from the docs/ directory?

  Error: ENOENT: no such file or directory, open '/Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/www/docs/styles/theme.css'


  Error: ENOENT: no such file or directory, open '/Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/www/docs/styles/page.css'

Should be relatively easy to resolve I think though.

@thescientist13 thescientist13 mentioned this issue Mar 20, 2021
Closed
@thescientist13
Copy link
Member Author

TODO were removed, here they are for reference

@thescientist13 thescientist13 changed the title resolve user workspace filesystem paths in HTML to consistent absolute served public paths resolve user workspace filesystem paths in HTML to consistent, normalized public paths May 29, 2021
@thescientist13 thescientist13 self-assigned this May 29, 2021
@thescientist13 thescientist13 changed the title resolve user workspace filesystem paths in HTML to consistent, normalized public paths resolve relative paths in HTML to normalized public paths May 29, 2021
@thescientist13 thescientist13 changed the title resolve relative paths in HTML to normalized public paths resolve relative paths in templates to expected workspace path May 29, 2021
@thescientist13
Copy link
Member Author

thescientist13 commented May 29, 2021 •
edited
Loading

Actually, in discovery, this looks like it is supported but only for top level pages / routes, anything nested will start to break because when at the top of the web root, as additional ../ will just effectively be ignored / swallowed, since there is way to go further up than the top of the webroot. So far so good...

However, if your routes go deep enough, then those ../ will end up getting "caught" by your routes

So given the above example

<head>
  <script  type="module" src="../components/header.js"></script>
  <script  type="module" src="../components/footer.js"></script>
</head>

An loading from the following routes will yield the following browser requests to the server

  • / - will resolve to /components/header.js
  • /getting-started/ - will also safely resolve to /components/header.js
  • /getting-started/quick-start - will resolve to /getting-started/components/header.js

So, somehow just need handle any ../'s in paths accordingly.

@thescientist13 thescientist13 mentioned this issue May 30, 2021
Merged
8 tasks
@thescientist13 thescientist13 changed the title resolve relative paths in templates to expected workspace path resolve deeply nested relative paths to expected workspace path May 31, 2021
@thescientist13 thescientist13 changed the title resolve deeply nested relative paths to expected workspace path resolve (deeply) nested relative paths to expected workspace path May 31, 2021
@thescientist13 thescientist13 changed the title resolve (deeply) nested relative paths to expected workspace path resolve (deeply) nested relative template paths to expected workspace path Jun 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@thescientist13 thescientist13

Labels
CLI enhancement Improve something existing (e.g. no docs, new APIs, etc) v0.13.0
Projects
None yet
Milestone
1.0
Development

Successfully merging a pull request may close this issue.

Enhancement/issue 435 deeply nested relative paths ProjectEvergreen/greenwood
1 participant
@thescientist13